On 19/01/2008, Dieter Maurer <[EMAIL PROTECTED]> wrote:
> 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".
I'd disagree with this description. From the Zope transaction
documentation, the order of methods is:
tpc_begin commit tpc_vote (tpc_finish | tpc_abort)
>From the descriptions of the various methods, a database adapter
supporting 2PC would prepare the transaction at commit(), and commit
or rollback that transaction in tpc_finish or tpc_abort respectively.
After preparing the transaction, the transaction should be committable
under normal circumstances, so it would have no reason to vote no as
part of tpc_vote().
I disagree that the lack of a tpc_vote() method makes the database
adapter a second class citizen: it simply reflects the fact that the
adapter makes up its mind at the commit() stage independent of what
other data managers do.
James.
_______________________________________________
DB-SIG maillist - DB-SIG@python.org
http://mail.python.org/mailman/listinfo/db-sig
