On Dec 28, 2011, at 5:19 PM, Mike Orr wrote: > On Wed, Dec 28, 2011 at 2:10 PM, Michael Merickel <mmeri...@gmail.com> wrote: >>>> Question: if multiple scoped sessions are created, each using >>>> ZopeTransactionExtension, would they all automatically fit into the >>>> global commit/rollback? >>>> >>>> Can we use the same ZopeTransactionExtension *instance* for all the >>>> scoped sessions, or would they each need a separate instance? >>> >>> yeah I'd like to get guidance from Chris McD or Lawrence Rowe on what a >>> multiple-session integration path might be (or if all apps should really use >>> one Session with zope.sqlalchemy). also my apologies for screwing up it's >>> name. >> >> >> Sorry, I'm not Chris or Lawrence, but I can tell you that the "transaction" >> package, which the ZTE and many other transaction-aware packages support, >> utilizes a threadlocal manager to which each ZopeTransactionExtension (ZTE) >> instance joins. The short answer is that if you have multiple ScopedSession >> objects that are using the ZTE, they will all be controlled by the same >> global transaction, and when pyramid_tm does transaction.commit() all of the >> sessions that are marked dirty will be committed. The ZTE supports two-phase >> transactions, but only if the ScopedSession is initialized with >> "twophase=True", thus ideally all sessions are done this way: >> >> DBSession >> = scoped_session(sessionmaker(extension=ZopeTransactionExtension(), >> twophase=True)) > > Is there any downside to setting twophase=True by default? Would it > make life more complex for simple applications? > > Also, again, I need to know whether it's safe to share a _zte instance > between two sessionmakers. Because if it's not, the docs will have to > warn people to use it only with the default session.
Twophase should not be on by default. On a DB like PG, it significantly alters the way transactions are done and can complicate management, as when things fail it can easily leave around prepared transactions that can lock up whole sets of tables until someone goes in and rolls them back manually. The flag shouldn't be on unless someone knows what they're doing and really wants that behavior. > > -- > Mike Orr <sluggos...@gmail.com> > > -- > You received this message because you are subscribed to the Google Groups > "pylons-discuss" group. > To post to this group, send email to pylons-discuss@googlegroups.com. > To unsubscribe from this group, send email to > pylons-discuss+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/pylons-discuss?hl=en. > -- You received this message because you are subscribed to the Google Groups "pylons-discuss" group. To post to this group, send email to pylons-discuss@googlegroups.com. To unsubscribe from this group, send email to pylons-discuss+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en.
