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 _______________________________________________ DB-SIG maillist - DB-SIG@python.org http://mail.python.org/mailman/listinfo/db-sig
