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

[M.-A. Lemburg]

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

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

-- 
Marc-Andre Lemburg
eGenix.com

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