On Jun 14, 3:14 pm, Michael Bayer <mike...@zzzcomputing.com> wrote:
> My advice would be, assuming you cannot isolate the issue inside a small test
> case, to trap the application at the point at which it appears to be opening
> a "mystery" SessionTransaction, dropping into pdb, and checking around why
> there's more than one Session in memory, as well as checking what
> gc.collect() accomplishes here.
Okay, I found the "phantom" transaction - it's being created in the
session.remove() call in the cleanup of the previous request, in the
following code in orm/session.py, in SessionTransaction.close():
if not self.session.autocommit:
self.session.begin()
I hadn't expected the SessionTransaction.close() to create a brand new
SessionTransaction, sorry I missed that. But this means that SQLA
starting state is different for two consecutive, identical requests -
the session.remove() for the first request leaves a state which causes
a different path to be taken by SQLA on the second request. How do I
completely clean up after each request so that the next identical
request is processed in the same way?
Regards,
Vinay Sajip
--
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.
