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
Repoze-dev@lists.repoze.org
http://lists.repoze.org/listinfo/repoze-dev
