[DB-SIG] Two-phase commit API proposal (was Re: Any standard for two phase commit APIs?)

[Stuart Bishop]

James Henstridge wrote:
> On 22/01/2008, Stuart Bishop <stuart at stuartbishop.net> wrote:
>> It seems that the formatID is unnecessary and just a requirement of the XA C
>> interface. Also, the xid() method you propose should be camelcase to match
>> the other type constructors, so Xid(gtrid, bqual=None) or
>> TransactionId(gtrid, bqual=None). If the xa_recover/list_prepared method
>> returns TransactionId objects they can contain platform specific information
>> too which is great (username, prepared timestamp & database for PostgreSQL
>> for instance).
> 
> Well, the DB-API does not actually expose any classes other than the
> exceptions.  The primary objects you work with are all created by
> factory functions/methods:

The camelcase suggestion was to match the other type constructors as
documented under "Type Objects & Constructors", such as Date, Time,
Timestamp, Binary.

>  * Connections from module.connect()
>  * Cursors from connection.cursor()
> 
> I was suggesting that transaction ID objects be created by either a
> module.xid() or connection.xid() factory function and not make the
> class object part of the API.

Sure - the class object doesn't need to be part of the API, but xa_recover
needs to return a list of something and the behaviour of those somethings
needs to be defined. I imagined that would be an object providing
.transaction_id & .branch_qualifier at a minimum, and the driver can add in
whatever platform specific attributes or behaviour it wants. The xid objects
can't be opaque as a transaction manager needs to be able to filter out the
relevant from irrelevant.

(From the other threads, I'm happy with tpc_ naming).

-- 
Stuart Bishop <stuart at stuartbishop.net>
http://www.stuartbishop.net/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: OpenPGP digital signature
Url : http://mail.python.org/pipermail/db-sig/attachments/20080122/ed0f52ec/attachment.pgp