[DB-SIG] Two-phase commit API proposal (was Re: Any standard for two phase commit APIs?)
M.-A. Lemburg
mal at egenix.com
Tue Jan 22 20:26:00 CET 2008
On 2008-01-22 19:52, Dieter Maurer wrote:
> M.-A. Lemburg wrote at 2008-1-22 13:42 +0100:
>> ...
>> 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.
>
> I learned (from James remark) that transaction ids belong to the
> transaction manager and not the resource.
>
> Thus, at least the individual "drivers" should not use different
> implementations for transaction ids.
You're right. I misunderstood which component manages the transaction
id (xid). It's the transaction manager, not the resource manager.
And it's the database modules that must accept whatever the TM
passes them, not the other way around.
Would a tuple (global transaction id, branch id) do the trick or
should we have two parameters on each API instead ?
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Jan 22 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
More information about the DB-SIG
mailing list