[DB-SIG] Any standard for two phase commit APIs?

Dieter Maurer dieter at handshake.de
Fri Jan 18 20:32:37 CET 2008


M.-A. Lemburg wrote at 2008-1-18 12:29 +0100:
> ...
>While this would seem desirable, it is not how the Zope TM
>works.
>
>Phase 1 is implemented by doing a vote on the success
>of the transaction. Phase 2 then finishes or aborts the transaction
>depending on the vote.
>
>If something fails in phase 2, there's no guarantee that partial
>commits can be undone.
>
>The .commit()/.rollback() calls on the database interface would
>be implemented in the phase 2 part.
>
>To avoid your scenario, the ZODB would have to detect the conflict
>during phase 1 (ie. the voting phase).

It does this indeed.

And it assumes that a resource manager accepts a vote only
when it can garantee that the subsequent "commit" will succeed (and
does not fail).

A resource manager needs to expose both a "vote" (with the above garantee)
and a "commit" in order to be a first class participant of
Zope's transaction system.

Relational database interfaces often lack the equivalent of a "vote".



-- 
Dieter


More information about the DB-SIG mailing list