[ZODB-Dev] what the transaction messages mean?

[Jeremy Hylton]

On Tue, 2003-04-29 at 13:53, Phillip J. Eby wrote:
> 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.

Thanks for writing this explanation.  I guess I can fill in with a
little background and some explanation of how ZODB4 works.  (The tpc
methods still show up in the storage interface.)

The transaction manager executes a two-phase commit protocol.  The goal
of two-phase commit (2PC) is to coordinate multiple independent
participants and guarantee that either all of them commit or none of
them do.  Every resource involved in the transaction, where a ZODB
Connection object is an example of a resource, is asked to prepare the
transaction.  When they prepare the transaction, they agree that they
can commit if asked.  So the prepare phase is the last opportunity to
raise an error.  If every participant prepare successfully, we move to
the second phase.  In this phase, every participant commits.  If any
participant fails to prepare, then every participant aborts.

The 2PC is implement using tpc_begin(), tpc_vote(), tpc_finish() in
ZODB3.  In ZODB4, it uses prepare() and commit(), where prepare()
performs the activities of tpc_begin() and tpc_vote().

The abort_sub() and commit_sub() method have to do with
subtransactions.  The subtransaction feature is now supported with the
savepoint() method.  The savepoint() does not involve making persistent
changes to the database, but allows you to rollback changes within a
single transaction.

Jeremy