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

[Stuart Bishop]

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 <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/20080122/52a62aeb/attachment.pgp