I have a case where I 'm using threadlocal scoped_sessions and I'm storing a file during a transaction. I want to delete the file if the transaction rolls back for any reason. To handle this I use the event system, something like so:
def write_data(file_path, data): with open(file_path, "w") as fp: fp.write(data) #set up a rollback handler... def delete_file(session, previous_transaction): os.remove(file_path) # <--- BREAKPOINT HERE ormSess = globalenv.LocalThreadData.OrmSess sa.event.listen(orm_session, "after_soft_rollback", delete_file, once=True) What I'm currently finding is that the delete_file handler is firing off long after the session it was hooked to is gone. I'm definitely calling .remove() on the scoped_session. When I put a breakpoint inside the handler, you can see that there are two entirely different sessions. The rollback is being called (code not shown) on an object at 0x7f18f8154910: >>> orm_session.rollback <bound method scoped_session.do of <sqlalchemy.orm.scoping.scoped_session object at *0x7f18f8154910*>> This fires off the handler for dead-and-gone (or so I thought) session. Down the stack and inside the handler you can see that the session passed in does not match: >>> session # the listener arg <sqlalchemy.orm.session.Session object at *0x5462b90*> Again, these are within the same call stack. Why would the handler on an old session be getting called? Am I misunderstanding something here? Is there a proper way to get rid of all event handlers on a session? I know that listeners can be removed individually, but I thought scoped_session.remove() would make this unnecessary. Thanks, 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.