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 _______________________________________________ DB-SIG maillist - DB-SIG@python.org http://mail.python.org/mailman/listinfo/db-sig
