> > do you mean to say event.listen(ormSess) here ?
Sorry... yes. Poor transcription/reduction. if you have set an event listener on a single session that is definitely > the > actual Session object and not the thread local or the scoped_session or > anything, and that Session is hit by .remove(), it will be garbage > collected, and the events associated with it will also go. Interesting comments on the possibility of registering a listener on the thread local or scoped_session. Given that it *is* firing (albeit from the grave when some unrelated session rolls back) I'm pretty sure it is on the right one, but I'll look into it. That is the only location I register a rollback handler, too. > It’s not too far fetched that there might be some > issue here, but this would need to be demonstrated. Is this issue only > under > high concurrency, is it relatively infrequent otherwise > Regarding frequency and concurrency, it is definitely not a high concurrency thing. This is happening repeatably in a large construct (unit/system testing a fresh system). I'll look into it further and try and reduce it. and what happens if > you actually remove() the event ahead of time? > I looked at removing event handling at time of scoped_session.remove(), but your event removal interface wants the actual handler. Not easy for me to get a hold of in the larger scope, given that the handler is a closure. I can do a nasty hack to check it, once I've sorted the other aspects. Russ > > -- You received this message because you are subscribed to the Google Groups "sqlalchemy" group. To unsubscribe from this group and stop receiving emails from it, send an email to sqlalchemy+unsubscr...@googlegroups.com. To post to this group, send email to sqlalchemy@googlegroups.com. Visit this group at http://groups.google.com/group/sqlalchemy. For more options, visit https://groups.google.com/d/optout.
