> Nope. This is a bug.
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``. Makes sense. I've created a bug report on launchpad here: https://bugs.launchpad.net/zodb/+bug/1153116 Let me know if that's good or if there's somewhere else I'd need to report it. Any idea when there would be a fix? On Sat, Mar 9, 2013 at 5:50 AM, Jim Fulton <j...@zope.com> wrote: > 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
