Tim Peters wrote:
[Tim Peters]

AFAICT, it would make more sense to move the logic for invoking callbacks
into TransactionManager.  Transaction() currently takes an optional
`sychronizers` argument that it never mutates, for which a
TransactionManager always passes its set of registered synchronizers.
Since ISynchronizer hooks are registered with a transaction manager
rather than with a transaction, it makes more sense to me for the
transaction manager to invoke them (as is, we're duplicating a TM
instance var inside every T).

Oh, fudge -- that doesn't work.  The callbacks take a transaction object as
an argument, so they pretty much have to be invoked by Transaction.  That
also makes it problematic to invoke them from TransactionManager.begin()
(what gets passed as the txn?

The transaction created by begin.

> Passing a brand new txn to a method called
"afterCompletion()" doesn't make a lot of sense on the face of it).

Of course not. OTOH, it makes a lot of sense to pass the new txn to a method named newTransaction. :)

data managers don't have any other method to call with a "sync the
underlying storage/data_source" meaning -- Connection.sync() certainly
doesn't have that meaning, since it also aborts the current transaction, and
wrt to all data managers, not just itself.

sync'ing via TM.begin() remains a puzzle.

ISynchronizer should grow a new method:

    def newTransaction(transaction):
        """Hook that is called at the start of a transaction.

The TM calls this method with the new transaction.

For Connections, this method will do what sync does now
sans the abort.


Jim Fulton           mailto:[EMAIL PROTECTED]       Python Powered!
CTO                  (540) 361-1714            http://www.python.org
Zope Corporation     http://www.zope.com       http://www.zope.org
For more information about ZODB, see the ZODB Wiki:

ZODB-Dev mailing list  -  ZODB-Dev@zope.org

Reply via email to