On Fri, Mar 8, 2013 at 9:54 PM, Siddhartha Kasivajhula <countvajh...@gmail.com> wrote: > Hi there, > I've been discussing this issue with Laurence Rowe on the pylons-dev mailing > list, and he suggested bringing it up here. > > I'm writing a MongoDB data manager for the python transaction package: > https://github.com/countvajhula/mongomorphism > I noticed that for a synchronizer, the beforeCompletion() and > afterCompletion() methods are always called once the synch has been > registered, but the newTransaction() method is only called when an explicit > call to transaction.begin() is made. Since it's possible for transactions to > be started without this explicit call, I was wondering if there was a good > reason why these two cases (explicitly vs implicitly begun transactions) > would be treated differently.
Nope. This is a bug. > That is, should the following two cases not be > equivalent, and therefore should the newTransaction() method be called in > both cases: > > (1) > t = transaction.get() > t.join(my_dm) > ..some changes to the data.. > transaction.commit() > > and: > > (2) > transaction.begin() > t = transaction.get() > t.join(my_dm) > ..some changes to the data.. > transaction.commit() Only if (1) was was preceded by an ``abort``. The definition of ``get`` is to get the current transaction, creating one, if necessary. Really, ``begin` and ``abort`` are equivalent. It might be better if there wasn't a ``begin`` method, as it's missleading. One should be an alias for the other. I'd be for deprecating ``begin``. The call to ``_new_transaction`` should be moved to the point in ``get`` where a new transaction is created, and ``begin`` should be made an alias for ``abort``. > In my mongo dm implementation, I am using the synchronizer to do some > initialization before each transaction gets underway, and am currently > requiring explicit calls to transaction.begin() at the start of each > transaction. Unfortunately, it appears that other third party libraries > using the transaction library may not be calling begin() explicitly, and in > particular my data manager doesn't work when used with pyramid_tm. > > Another thing I noticed was that a synchronizer cannot be registered like > so: > transaction.manager.registerSynch(MySynch()) > .. and can only be registered like this: > synch = MySynch() > transaction.manager.registerSynch(synch) > > ... which I'm told is due to MySynch() being stored in a "WeakSet" which > means it gets garbage collected. Currently this means that I'm retaining a > reference to the synch as a global that I never use. Just seems a bit > contrived so thought I'd mention that as well, in case there's anything that > can be done about that. This is to prevent memory leaks. Normally, the synchronizier is associated with a database. For example, the synchronizers are database connection methods. A stand-alone synchronizer seems weird to me. Jim -- Jim Fulton http://www.linkedin.com/in/jimfulton Jerky is better than bacon! http://zo.pe/Kqm _______________________________________________ For more information about ZODB, see http://zodb.org/ ZODB-Dev mailing list - ZODB-Dev@zope.org https://mail.zope.org/mailman/listinfo/zodb-dev
