[DB-SIG] Distributed Transaction framework

[Jim Fulton]

"M.-A. Lemburg" wrote:
> 
> 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.).

This is pretty pointless if your goal is distributes transactions.

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

> 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. :)
 
Jim

--
Jim Fulton           mailto:jim@zope.com       Python Powered!        
CTO                  (888) 344-4332            http://www.python.org  
Zope Corporation     http://www.zope.com       http://www.zope.org