Re: PATCH: two phase commit
"James Henstridge" <[email protected]>
| Newsgroups | gmane.comp.python.db.psycopg.devel |
|---|---|
| Message-ID | <[email protected]> |
On 18/01/2008, Federico Di Gregorio <fog-NGVKUo/i/[email protected]> wrote: > Il giorno ven, 18/01/2008 alle 00.08 +0900, James Henstridge ha scritto: > > These are the basic operations needed to plug a psycopg2 connection > > into a transaction manager so it would be possible to properly > > participate in Zope two phase commit, as an example. > > > > I've included basic tests of the new methods. > > Mm.. I am sorry but I don't like adding another 3 methods to the > connection object. Also before going on extending the API it is > customary to seek comments on the DBAPI list where other people may > already have implemented the feature (two phase commit here). I've sent an email to the db-sig mailing list about this now: http://mail.python.org/pipermail/db-sig/2008-January/005290.html > Anyway, my argument against this API is that passing around the > transaction xid it isn't very pythonic. A better approach would be to > create a transaction object that olds the xid and has commit and > rollback methods. Also, the prepared transaction can be commited or > rolled back from a different session so it would be nice to have the > ability to give the transaction object to a new connection, etc. > > trans = conn.prepare_transaction() # autogenerate xid > trans = conn.prepare_transaction(xid) # xid as argument > trans = conn.prepare_transaction(told) # extrac xid from old trans > > print trans.xid -> prints the xid > > trans.commit() > trans.rollback() I am not convinced that separating off the transaction commit API from the connection is not a good idea. At one level, I am not hugely concerned by the API, since it is unlikely to be used by many programmers -- instead only being used by glue code that hooks the database connection into the transaction manager (which is often DB specific anyway). I did take a look for existing adapters for ideas and found two others: The kinterbasdb module adds a prepare() method to the connection object. After calling this method, the standard commit() and rollback() methods can be used to perform the second phase of the commit. This would be implementable in psycopg2, with the following caveats: 1. we'd need to be able to generate unique transaction identifiers. 2. it provides no way to commit a transaction prepared with another connection. The pymqi project provides a patch to DCOracle2 to expose Oracle's XA integration. This does not add any explicit API to the connection object as the transaction manager integration appears to be at the C level. Frustratingly, DCOracle2 has a prepare() method on its connection object that does something completely different (prepared statement support). So it is not clear what the API should look like. James.