[DB-SIG] Two-phase commit API proposal (was Re: Any standard for two phase commit APIs?)
M.-A. Lemburg
mal at egenix.com
Thu Jan 24 15:41:09 CET 2008
On 2008-01-24 15:36, M.-A. Lemburg wrote:
> On 2008-01-24 02:44, James Henstridge wrote:
>> I've had a bit more time to think about this, and have two proposals
>> on how to handle transaction IDs. I think they offer equivalent
>> functionality, so the choice comes down to what we want the API to
>> look like.
>>
>> Proposal 1:
>> * Plain string IDs should work fine as transaction identifiers for
>> applications built from scratch with that assumption: they would
>> need to identify the global and branch parts in their own way.
>>
>> * A plain string can be stuffed inside an XA style transaction
>> identifier, even if it isn't making use of all the different
>> components.
>>
>> * Therefore, all methods accepting transaction IDs should accept
>> strings.
>>
>> * As some transaction IDs in the database might not match this simple
>> form, there are two options for the recover() method:
>> 1. return a special object that represents the transaction, which
>> will be accepted by commit()/rollback(). How string-like must
>> these objects be?
>> 2. omit such transaction IDs from the result.
>>
>> * For databases that support more structured transaction IDs (such as
>> those used by XA), the 2PC methods may accept objects other than
>> strings.
>>
>>
>> Proposal 2:
>>
>> * Many databases follow the XA specification, so it makes sense to use
>> transaction identifiers structured in the same way.
>>
>> * For databases that do not use XA-style transaction IDs, it is
>> usually possible to serialise such an ID into a form that it can
>> work with.
>>
>> * Therefore, all methods accepting transaction IDs should accept
>> 3-sequences of the form (formatID, gtrid, bqual).
>>
>> * For databases using non-XA transaction IDs, it is possible that some
>> transaction IDs might exist that do not match the serialised form.
>> The recover() method has two options:
>> 1. return a special object representing the ID that will be
>> accepted by commit()/rollback(). Such an object should act
>> like a 3-sequence.
>> 2. omit such transaction IDs from the result.
>>
>> * For databases not using XA-style transactions, the 2PC methods may
>> accept objects other than 3-sequences as transaction IDs.
>>
>>
>> Both of these proposals seem to get rid of the main points of contention:
>> * removes the xid() constructor from the spec.
>> * allow use of simple objects (strings or tuples) as transaction IDs
>> * provides an obvious way to expose database-specific transaction IDs.
>
> I'm coming to agree with Stuart that the conn.xid() might actually
> help us with this.
>
> So I'd be in favor of proposal 2 and an .xid() constructor that
> returns an object which provides a 3-sequence interface, e.g.
>
> # Wrap the IDs for use by the database module
> xid = conn.xid(fid, gid, bid)
>
> # Use the xid
> conn.tpc_begin(xid)
> conn.tpc_prepare(xid)
> ...
>
> # Unwrap the IDs:
> fid, gid, bid = xid
Plus require that all three components are strings to avoid the
None issue.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Jan 24 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
More information about the DB-SIG
mailing list