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 at
http://groups.google.com/group/sqlalchemy?hl=en.
