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

[Stuart Bishop]

M.-A. Lemburg wrote:

>> If we use an object, these issues go away:
> 
> I'm not sure I understand... a tuple *is* an object after all :-)

An object we can't define the constructor of.

> Why does '' get converted to None on output ?

Because if, say, on MySQL you do """XA PREPARE 'foo'""", MySQL will fill in
the branchid and formatid with defaults - in MySQL's case '' and 1
respectively.

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

The databases that support XA style xids have to be able to round trip with
the defined C data structure. This structure is the formatid, the length of
the global transaction id, the length of the branch id, and an array of
bytes containing the concatenated ids. In this structure there is no way to
differentiate a NULL from an empty string or a NULL formatid from whatever
integer you map NULL to.

I guess validation of the xid could be done by the driver in tpc_begin(),
tpc_commit(), tpc_rollback() and an exception raised if the driver detects
that round tripping via the database is not possible.

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

I don't follow this. We have to specify what object can be passed to
tpc_begin and is returned from tpc_recover. The only issue is if it is if we
force this to be a 3-tuple or whatever the driver decides to return from a
module level Xid() method.

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

I wouldn't say 'may be worthwhile'. I'd go for 'is essential'. If you can't
inspect the results from tpc_recover(), the method is pointless.

-- 
Stuart Bishop <stuart at stuartbishop.net>
http://www.stuartbishop.net/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: OpenPGP digital signature
Url : http://mail.python.org/pipermail/db-sig/attachments/20080124/ce425f43/attachment.pgp