On Nov 7, 2008, at 10:17 AM, joelanman wrote:
> > Thanks for that - I'll check out those options - I am using Beaker for > cache and sessions. OK, with Beaker, if you are caching things on a dynamically generated key, such as a key constructed from arbitrary parameters, I strongly recommend you work with Beaker 1.1 which is not yet released, but is available from mercurial. Previous versions will store an in-memory record for each unique key, and if you have an arbitrary number of keys then you'll have an arbitrary growth in memory. 1.1 has a significant rearrangement of things so that this problem is resolved. Try disabling Beaker entirely to see if that clears the issue. > In the meantime I found this post about a leak in MySQLdb 1.2.2 when > using charset=UTF8, which I am: > > http://jjinux.blogspot.com/2008/09/python-debugging-memory-leaks.html > > I'm using SQLA to do all database activity - would this leak be > relevant? I tried out his test program there and indeed it leaks memory like a wellspring, even if you put a cursor.close() in there. The good news is, when using SQLAlchemy with MySQL, you want to connect using ? charset=utf8&use_unicode=0 , which disables MySQLdb's conversion of python bytestrings into unicode objects, since SQLA handles this in a more finely-controllable way (not to mention, non-leaking.... :) ). When I add use_unicode=0 to the test script, the memory leak ends. > Also - if you have time, could you explain your point about __del__? > If I don't define it and call session.close(), will the session close > itself anyway when the controller that called it expires? The session will actually result in everything being closed out if it just falls out of scope. However, this might place some burden on the garbage collector to take care of it and wont necessarily close things out immediately. I don't know what web.py's architecture offers, but usually session management is assembled into a web framework by wrapping requests with a session open/close block, so that its handled in all cases without reliance on gc. This is described at http://www.sqlalchemy.org/docs/05/session.html#unitofwork_contextual_lifespan . --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "sqlalchemy" group. To post to this group, send email to sqlalchemy@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en -~----------~----~----~----~------~----~------~--~---
