[DB-SIG] XID format (was: Two-phase commit API proposal)

Federico Di Gregorio fog at initd.org
Thu Jan 24 09:58:59 CET 2008


The problem here seems to be that simple strings should be supported
(xid, in the end are simple SQL strings for most backends) while it
should be possible to access single parts (format, gtrid, bqual) to play
well with the transaction managers. The thing to notice is that even if
you mix the two styles, after you compose the parts in the final xid, no
two xids can be the same string. So, what about using a 4-tuple?

(full, format, gtrid, bqual)

The application layer can pass just the 'full' parameter (a sting)
representing the xid directly, or set 'full' to None and let the driver
build the string out of the other three parts (and fill 'full' for later
reference.)

recover() returns a tuple with the 'full' slot always valorized and, if
it is possible it also fills the other three slots parsing the xid.

This way one has access to the full xid and if it was built from parts
to the single parts too. A transaction manager can discover if a
recovered() transaction belongs to it by checking the 'format' (it can
be None) and there is no need to drop xids from recover() calls.

federico

-- 
Federico Di Gregorio                         http://people.initd.org/fog
Debian GNU/Linux Developer                                fog at debian.org
INIT.D Developer                                           fog at initd.org
           Purtroppo i creazionisti non si sono ancora estinti. -- vodka
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Questa =?ISO-8859-1?Q?=E8?= una parte del messaggio
	firmata digitalmente
Url : http://mail.python.org/pipermail/db-sig/attachments/20080124/acba9f62/attachment.pgp 


More information about the DB-SIG mailing list