[DB-SIG] Two-phase commit API proposal (was Re: Any standard for two phase commit APIs?)
mal at egenix.com
Fri Jan 25 10:45:52 CET 2008
On 2008-01-25 01:54, James Henstridge wrote:
>>>> 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.
> So is the 3-sequence behaviour intended to allow application code to
> inspect a transaction ID, or are tpc_begin(), etc expected to accept
> arbitrary 3-sequences too?
I'd say we put the .xid() as interface between the TM and
the .tpc_*() methods, like Stuart suggested.
That way, the TM has a clear interface to construct an XID
interface, while the RM has control over what is passed to its
.tpc_*() methods and can also use other means of creating
these object (if needed).
By using the 3-sequence interface, the TM can also easily
recover the data it passed to the .xid() constructor when
getting back data from .tpc_recover(), so it is round-trip
>>> # Wrap the IDs for use by the database module
>>> xid = conn.xid(fid, gid, bid)
>>> # Use the xid
>>> # Unwrap the IDs:
>>> fid, gid, bid = xid
>> Plus require that all three components are strings to avoid the
>> None issue.
> If we are going with 3-part XA-style transaction IDs, the format ID
> should be a non-negative 32-bit integer and the other two should be
> strings with a maximum length of 64 bytes (possibly with some
> restrictions on allowed characters?).
Ok, if that's the GCD of what backends use, let's go with that.
Professional Python Services directly from the Source (#1, Jan 25 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