M.-A. Lemburg wrote: > It only needs to be defined in the context of the module exposing > that recover API, since you'd only pass it back to the methods of > that same API. > > We could just describe the transaction id as object in the spec and > then have the modules decide what type this maps to, e.g. one module > might want to use a tuple (or even namedtuple) for this, another > might not want to bother at all and use the internal representation > mapped to a string or bytes object.
From the XA pdf you linked to earlier on xa_recover:
"A transaction manager calls xa_recover() during recovery to obtain a
list of transaction branches that are currently in a prepared or
heuristically completed state.
[...]
"It is the transaction manager’s responsibility to ignore XIDs that do
not belong to it.
So if you where to implement an XA like interface around this, how can a
transaction manager filter out the irrelevant XIDs if is cannot interrogate
them?
If behaviour of the xids returned by tpc_recover is not defined, we need
another method to decompose an xid into its global transaction id and its
branch id.
--
Stuart Bishop <[EMAIL PROTECTED]>
http://www.stuartbishop.net/
signature.asc
Description: OpenPGP digital signature
_______________________________________________ DB-SIG maillist - DB-SIG@python.org http://mail.python.org/mailman/listinfo/db-sig
