[Shane Hathaway] >> Would it be sensible for ZODB to do the equivalent of sync() when users >> call transaction.begin()? That's what I tend to expect it to do >> anyway--it takes some effort to remember that it doesn't.
[Jim Fulton] > Yes, or commit, or abort. That's what Tim and I were pondering in a part > of the message you didn't quote. :) > > I imagine that we'll make this so today. We didn't, but I'm looking at it today's today. begin() is really a different case than commit()/abort(): the latter two automagically trigger registered afterCompletion() callbacks, but begin() does not. Despite the small cognitive dissonance involved, I'm inclined to make TransactionManager.begin() invoke registered afterCompletion() callbacks. (Note that Transaction.begin() is deprecated, and I'm not keen to add new functionality to deprecated stuff.) 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). _______________________________________________ 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