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

[M.-A. Lemburg]

On 2008-01-22 13:34, Stuart Bishop wrote:
> 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. 

It only needs to be defined in the context of the module exposing
that recover API, since you'd only pass it back to the methods of
that same API.

We could just describe the transaction id as object in the spec and
then have the modules decide what type this maps to, e.g. one module
might want to use a tuple (or even namedtuple) for this, another
might not want to bother at all and use the internal representation
mapped to a string or bytes object.

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

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Jan 22 2008)
>>> Python/Zope Consulting and Support ...        http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ...             http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...        http://python.egenix.com/
________________________________________________________________________

:::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,MacOSX for free ! ::::


   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
    D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
           Registered at Amtsgericht Duesseldorf: HRB 46611