Chris, This is what the combination of repoze.tm2/transaction and zope.sqlalchemy does for you. You don't have to do anything special other than that.
Laurence On Apr 28, 2:37 pm, Chris Withers <ch...@simplistix.co.uk> wrote: > Hi All, > > I'm still trying to get an answer on this... > > Am I right in understanding that the basic session lifecycle should be: > > try: > <use session> > session.commit() > except: > log() > session.rollback() > finally: > session.remove() > > The structure I've traditionally used with transactions has been: > > try: > <use session> > except: > log() > session.rollback() > else: > session.commit() > > Is this okay? Why would the first setup be preferable? > (ie: what's wrong with my location of the commit() call?) > What happens when the remove() call is omitted()? > > For me, the above will commonly be used in the context of a wsgi app > (BFG to be precise). How do people manage the lifecycle in that context > (ie: multi-thread, scoped sessions)? > > My thoughts were on a bit of "wsgi middlewear" so that I can manage the > app's sessions without having to fiddle with BFG's wsgi application. > I'll be using sessions in multiple databases to boot. > > Is there existing middlewear that does this? Is it a good/bad idea? > > cheers, > > Chris > > -- > You received this message because you are subscribed to the Google Groups > "sqlalchemy" group. > To post to this group, send email to sqlalch...@googlegroups.com. > To unsubscribe from this group, send email to > sqlalchemy+unsubscr...@googlegroups.com. > For more options, visit this group > athttp://groups.google.com/group/sqlalchemy?hl=en. -- You received this message because you are subscribed to the Google Groups "sqlalchemy" group. To post to this group, send email to sqlalch...@googlegroups.com. To unsubscribe from this group, send email to sqlalchemy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en.
