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
--
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.
