Possible leak of objects in Unit of Work

[Former user]

After flushing and clearing a session, a number of unit of work task objects still exist in memory. These can build up over time in a long running script and begin to affect the performance of the program. I've tried to track down the source of the leak but haven't managed to find it yet, I'm afraid.

The attached script demonstrates the problem both in 0.2.8 and the latest svn. It displays the number of UOWTask objects after creating a number of mapped objects, saving, flushing and clearing the session.

[Former user]

Script demonstrating the problem

[Former user]

Just to clarify the problem is in the last section of output from the script, 'After clear'. The identity map is empty, so the session has been cleared properly, but there are still 24 unit of work tasks somewhere in memory. (That is with 0.2.8. With current svn (4078c7606f4ff7dcdd128392dd69dc4fc53a872a), it seems to have dropped to 22)

[Mike Bayer]

if you add this step:

   gc.collect()

   dump_objects(session, 'After gc collect')

the number of UOWTask objects goes back to zero. how is this a bug ?

[Former user]

I'm sorry - you're absolutely right. I'm having a problem in a bigger script, and I had used gc.collect() there, but I forgot to put it in when I made this small test case. The problem I'm actually seeing is that when I make a series of changes and then commit a transaction, only some of those changes actually get committed. For some reason I noticed the outstanding UOWTasks before noticing that my data wasn't actually in the database! However, this is almost certainly a bug on my side - I'm using SessionContext in order to work with TurboGears, and I think I've got confused. Time to go back to basics :-)

Thanks a lot for the speedy response, and sorry to waste your time...

[Mike Bayer]

no problem at all ! let me know if you need any help with your program (and can I say motorola uses SQLAlchemy ? ;) )