King Simon-NFHD78 wrote: > 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.
I have now ;-) > 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. Any ideas in the case where you're using two phase commit? I'm likely to use repoze.tm2, which has a process that looks roughly like: try: <use session> except: session.rollback() raise else: try: <do first phase of commit for other resources> session.prepare() except: session.rollback() raise else: session.commit() Is this sequence correct? If not, what should change? > 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. Surely that's a good thing? When would it not be a good thing? (repoze.bfg has a faily warty way of calling session.remove, I'd like that to go away if it's not necessary) The only worry I have is about releasing MySQL connections back to the pool rather than slowly consuming them all over time... cheers, Chris _______________________________________________ Repoze-dev mailing list Repozeemail@example.com http://lists.repoze.org/listinfo/repoze-dev