> -----Original Message----- > From: sqlalchemy@googlegroups.com > [mailto:sqlalch...@googlegroups.com] On Behalf Of Chris Withers > Sent: 28 April 2010 14:37 > To: sqlalchemy@googlegroups.com > Subject: [sqlalchemy] session lifecycle and wsgi > > 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()? >
Have you read http://www.sqlalchemy.org/docs/session.html#lifespan-of-a-contextual-ses sion - it describes typical usage of a scoped session in a web application. In your traditional structure, you could get an exception during session.commit() which would not be handled in your exception handler. I believe (but I'm not certain) that after any kind of database exception, it is recommended that you roll back the existing transaction, as it is likely to be invalid anyway. Session.remove() ensures that the current session is removed from the scoped session registry. If you don't do this, I think that the next time this thread calls Session(), it'll get the old session back again, rather than creating a new one. Simon -- 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.
