[DB-SIG] Distributed Transaction framework

[M.-A. Lemburg]

Jim Fulton wrote:
> 
> > > BerkeleyDB supports XA. I'm pretty sure Oracle does too.
> >
> > I read about support in IBM's DB2 -- as I read it, there are basically
> > two options:
> >
> > 1. You let DB2 play the role of the transcation manager . In that
> >    case, there are no APIs to be called -- the database works out
> >    the transactions itself. You only have watch out to setup the
> >    database driver accordingly (e.g. disable thread support in the
> >    driver, tell it to do two-phase commits, etc.).
> 
> This is pretty pointless if your goal is distributes transactions.

Not really: this setup is for connecting to more than one DB2 database
and then coupling the transactions for the two or more connections.
 
> > 2. You use a per-process transaction manager (TM). This scenario is
> >    similar to 1. in that you have to setup the database driver in
> >    the same way. The mayor difference here is that you have to
> >    use the TM's transaction API .commit() and .rollback() instead
> >    of the database driver ones.
> 
> Do they support third-party transaction monitors?

Yes, MS TM on Win NT and two other on mainframes (can't remember the
names).
 
> ...
> 
> 
> > Perhaps what you really want here is a central data source management
> > object within a Python process. All database activitiy would then be
> > managed by this instance and it could also implement XA style coupled
> > transactions ?!
> 
> Something like that. It should support multiple simultaneous transactions
> within a process.
> 
> > I'm using something like this in the eGenix Application
> > Server to implement coupled transcations and it works great. The
> > main idea is to use the management object's .commit() and .rollback()
> > APIs instead of the connection object ones. Of course, there may
> > be other scenarios where it is not feasable to couple *all*
> > transactions.
> 
> I'm not sure what you mean here. Did you mean to say
> resource managers?

Well, you normally connect to different data sources (resource manager
in XA terms) and then have to deal with the problem of how to
handle errors which cause the HTTP request to fail. I suppose
you have the same problem in Zope. For these applications,
things are easy to manage: you simply issue a rollback on all
open connections.

However, there may be other applications such as GUI applciations
which use multiple data sources, but in different scopes, e.g.
the application could have a set of system internal connections
to various data sources and another set of user data specific
connections. In such a scenario you would want to couple the
user data connections only and leave the system internal
connections alone.
 
> > To handle such a case, we'd need something more XA
> > like in order to couple various transactions into a single
> > logical entity.
> 
> You lost me. :)

Oops :-)

Example:

Say you have data sources A, B, C, D. Now it may be feasable
for your application to couple transactions on sources A and B
only, while leaving the transactions in C and D uncoupled.

In case of an error, you'd only rollback A and B. C and D
would not see the rollback. A typical case is where A and
B are connections to databases which you need to update,
while C and D are read-only databases.

-- 
Marc-Andre Lemburg
CEO eGenix.com Software GmbH
______________________________________________________________________
Company & Consulting:                           http://www.egenix.com/
Python Software:                   http://www.egenix.com/files/python/