On Sunday, March 3, 2013 4:59:58 PM UTC-8, Sid K wrote: > > Ok, it looks like the synchronizer instance needs to remain in the calling > scope for the synchronizer to work. This code (Laurence) works: > > synch = MySynch() > transaction.manager.registerSynch(synch) > > while this code (what we were doing earlier) doesn't: > > transaction.manager.registerSynch(MySynch()) > > Is this a bug or is it supposed to work this way? >
The TransactionManager keeps the reference to the synchronizer in a WeakSet, so you will need to keep a reference to the synchronizer around some other way in order to avoid it being garbage collected. > Now, regarding the newTransaction() interface method -- this actually > looks very handy and may be just what I need for a mongodb data manager > that I'm writing. But it looks like it's only called when there is an > explicit call to transaction.begin(), which apparently isn't necessary to > use the transaction machinery as it happens implicitly by just using > transaction.get() and then commit()ing. These implicitly begun transactions > don't appear trigger the newTransaction() method in the synchronizer. Is > there any way to make it trigger without an explicit begin()? (this should > probably be the default behavior?) > I think this might be worth bringing up on zodb-dev, I'm not sure why the distinction exists. In Pyramid and Zope the transaction will always be begun explicitly at the start of a request. btw I'm not able to find any of these interface methods by using help() or > dir() on the interfaces in transaction.interfaces. All of the interfaces > appear to show exactly the same set of properties and methods... though I > do see them if I look directly in the transaction/interfaces.py source. is > there another way to introspect these? > An interface object is not a class, to access the methods and attributes defined in an Interface you can use iface.names() and iface[name']. I've not used MongoDB myself, but what are you hoping to gain from the Synchronizer? A DataManager sounds more appropriate. You'll only be able to handle a single document update atomically with MongoDB, but that case should be able to integrate safely with the two phase commit protocol by committing during tpc_vote while ensuring the data manager sort key sorts last (take a look at one phase variant of zope.sqlalchemy's DataManager.) For multi-document updates you probably want to treat them more like zope.sendmail does and add them to a queue which then processes them asynchronously. Laurence -- You received this message because you are subscribed to the Google Groups "pylons-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to pylons-devel+unsubscr...@googlegroups.com. To post to this group, send email to pylons-devel@googlegroups.com. Visit this group at http://groups.google.com/group/pylons-devel?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
