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

[M.-A. Lemburg]

On 2008-01-23 14:11, Stuart Bishop wrote:
> M.-A. Lemburg wrote:
>> So we do need to store the "formatID" as well ?
> 
> It looks like yes we do. MySQL's syntax for xids allows an optional formatid
> and this is returned by XA RECOVER. In MySQL, it is a number rather than a
> string. Assuming that any system that uses more than a simple string for the
> xid is doing so to map onto the XA specification, we could safely represent
> xids as a 3-tuple of (unicode, unicode, integer).
> 
> How to deal with None's and empty strings needs to be thought out though to
> avoid round trip edge cases:
> 
>>>> con = connect('')
>>>> xid = ('g', '', None)
>>>> con.tpc_begin(xid)
>>>> con.tpc_prepare()
>>>> con.tpc_recover()
> [('g', None, 1)]
>>>> con.tpc_recover()[0] == xid
> False
> 
> '' and None for the gtid and brid would be equivalent, and 1 and None would
> be equivalent for the format_id (1 is the default format id in MySQL). To
> avoid round trip issues with tuples, only one of these values should be allowed.
> 
> If we use an object, these issues go away:

I'm not sure I understand... a tuple *is* an object after all :-)

Why does '' get converted to None on output ?

The database module
should not try to change the object in any way (regardless of whether
it's a string, tuple, custom sequence like object, etc.). At least
that's the theory.

Or is this a side-effect of MySQL doing some internal mapping of
the tuple contents to some internal table ?

>>>> con = connect('')
>>>> xid = Xid('g', '')
>>>> tuple(xid)
> ('g', None, 1)
>>>> con.tpc_begin(xid)
>>>> con.tpc_prepare()
>>>> con.tpc_recover()
> [<Xid 'g', None, 1>]
>>>> con.tpc_recover()[0] == xid
> True
> 
>> Given that the formatID is used for some purpose as well (probably
>> just as identification of the TM itself), I guess we'd have
>> to use a 3-tuple (format id, global transaction id, branch id).
>>
>> Modules should only expect to find an object that behaves like
>> a 3-sequence, they should accept whatever object is passed to
>> them and return it for the recover method.
>>
>> This leaves the door open for extensions used by the TM for XID
>> objects.
> 
> I don't see a technical problem with the tuple apart from the round tripping
> issue above and someone might have a nice solution to that. Subjectively, I
> think an object reads better though, particularly as in many cases you will
> only want to bother specifying one or maybe two of the three parts.
> Xid('foo') vs. ('foo', None, None).

I think we shouldn't restrict the TM by specifying a particular
object. After all, the DB-API is about the RM, not the TM.

However, it may be worthwhile to have the RM at least peek
into the XID object and that's why I think we should require
the XID object to implement the __getitem__ protocol and
have the first three positions defined as (format id,
global transaction id, branch id).

This should leave enough room for the TM.

> Is CamelCase of xid 'Xid' or 'XID' or 'XId' ?

Good question. XID itself is an abbreviation. I tend to
leave those alone and use all-capital-letters for classes.

Note that since the TM will create the XIDs, we don't need
to worry about a method or API to generate them.

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Jan 23 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