[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. :)
> OTOH,
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
-- 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: http://www.zope.org/Wikis/ZODB/
ZODB-Dev mailing list - ZODB-Dev@zope.org http://mail.zope.org/mailman/listinfo/zodb-dev
