[DB-SIG] Distributed Transaction framework

[M.-A. Lemburg]

Jim Fulton wrote:
> 
> > > > The DB API already exposes .commit() and .rollback(). What other
> > > > APIs do you have in mind here ?
> > >
> > > These are non-distributed APIs. Many databases have separate
> > > APIs to support distributed transactions, typically conforming to
> > > the X/Open XA distributed transaction standard. Unfortunately, the
> > > APIs aren't part of the DB API. We should consider adding these.
> >
> > Hmm, the only references to databases and repositories supporting
> > these APIs I could find are related to object databases and
> > distributed relational database scenarios.
> 
> 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.).

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.

The first option does not expose any APIs to the user. The second
depends on the used use TM, but also requires a lot of extra
application awareness in order to work.

It doesn't look like a framework would help a lot to make this
easier to setup... 

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 ?! 

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. To handle such a case, we'd need something more XA
like in order to couple various transactions into a single
logical entity.

> ...
> 
> > > > could you put up a summary
> > > > of your findings somewhere on the net ?
> > >
> > > Of course.
> >
> > Great. I'd suggest to use the PEP format as basis since it integrates
> > nicely with the tools we have available for handling these.
> 
> Good idea. So the ultimate product of this BOF (and the Persistence
> BOF) should be a PEP.

Right.

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