[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:36:30 CET 2008


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

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