[DB-SIG] Two-phase commit API proposal (was Re: Any standard for two phase commit APIs?)
stuart at stuartbishop.net
Tue Jan 22 14:09:58 CET 2008
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
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
Stuart Bishop <stuart at stuartbishop.net>
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 189 bytes
Desc: OpenPGP digital signature
Url : http://mail.python.org/pipermail/db-sig/attachments/20080122/52a62aeb/attachment.pgp
More information about the DB-SIG