[ZODB-Dev] what the transaction messages mean?

[Phillip J. Eby]

At 12:45 PM 4/29/03 -0400, Nicholas Henke wrote:
>On Mon, 2003-04-28 at 05:47, Adam Groszer wrote:
> > Dear All,
> >
> > Can you please explain me what the transaction messages (tpc_begin,
> > tpc_abort, tpc_vote, tpc_finish, commit, abort, abort_sub, commit_sub) mean
> > in ZODB and what they do?
> >
>
>I would be very interested in seeing these explained -- especially in
>the context of transactions. The thread on PROPOSAL: Explicit
>Transactions for ZODB4 would make a ton more sense... :)

Actually, no, because the messages are quite different in ZODB4.

As long as I've started writing this email, though, I suppose I might as 
well offer an explanation of the messages for ZODB3:

tpc_begin - indicates the beginning of two-phase commit.  Sent from a 
transaction to all data managers during a transaction.commit().

tpc_abort - indicates that two-phase commit failed, and the transaction 
must be rolled back.  Sent by a transaction to all data managers that it 
sent tpc_begin to, if the commit process fails.  Note that a DM may receive 
abort(ob) calls in addition to this message, or in place of it (if 
tpc_begin wasn't yet called on the DM when the abort began, or if the abort 
didn't occur as a result of an error in the commit process).

tpc_vote - this is the last chance for a data manager to back out of 
committing.  If the DM can't absolutely guarantee it will successfully 
commit, it should raise an error message.  This is sent by the transaction 
to all participating data managers, after tpc_begin and any commit(ob) 
messages.

tpc_finish - go ahead and actually commit.  Sent by the transaction to all 
participating data managers if and only if all tpc_vote calls returned 
successfully.  tpc_finish must not raise any exceptions, or the system will 
enter the "hosed" state.  :)

commit(ob) - sent to a data manager by the transaction (after tpc_begin) to 
indicate that 'ob' is a changed object the DM is responsible for committing.

abort(ob) - sent to a data manager by the transaction to indicate that 'ob' 
is an uncommitted object whose state should be discarded.  This method is 
only called for objects that were not yet passed to the DM's 'commit()' method.


None of this is relevant to ZODB4.  ZODB4 already uses a more "lightweight" 
protocol that does not require transactions to keep track of the changed 
objects.  Data managers are responsible for their own "dirty" lists, so 
there are no commit(ob)/abort(ob) messages, to name just one example of the 
differences.  For an understanding of the ZODB4 transaction protocol, I 
recommend reading the transaction package, especially its 'interfaces' 
module.  The ZODB4 transaction package is much simpler and has fewer 
complex interactions with the rest of ZODB than ZODB3 transactions do.