The thing is that in the original scenario I create a single sqlsoup object and call multiple times to the same code that uses the same tables so I would think it would use the same bounded objects it created.
I will look into _cache but from the documentation I understood that it's for objects being worked on. In any case I didn't see something in the source code that clears _cache other than killing the sqlsoup object. Then again it was a quick look. I will check _cache. Thanks, Eran On 25 ביול 2010, at 18:40, Michael Bayer <mike...@zzzcomputing.com> wrote: > > On Jul 25, 2010, at 6:10 AM, Eran Sandler wrote: > >> Hello all, >> >> I'm using SqlSoup with PyODBC to access MSSQL under Tornado (without >> using process forks). >> >> Since tornado is an event based server, I create the SqlSoup object at >> the application init and use it when I get various requests. >> I keep on seeing an increase of memory related to SqlSoup and >> SqlAlchemy. >> >> At first, I thought it was due to the fact that SqlSoup always uses a >> Session and since I never create or delete session it may cause this >> problem. I therefore added calls after each request such as: >> >> db.commit() >> db.expunge_all() >> db.session.close() >> >> However it doesn't seem to be helping much. >> >> The dictionaries that seems to be increasing in size are: >> dict of sqlalchemy.orm.attributes.ScalarAttributeImpl >> dict of sqlalchemy.orm.properties.ColumnProperty >> dict of sqlalchemy.orm.strategies.ColumnLoader > > > Those are objects that correspond to a class that is mapped. SQLSoup > creates classes dynamically and then maps them anytime you say > sqlsoup.<somename> - a class called <somename> and a corresponding Table are > created, columns loaded from the database, and you get the mapped class back. > The structure is then stored within the SQLSoup instance and returned > again upon subsequent access. > > So if you were loading an arbitrarily large set of distinctly named tables > from your SQLSoup, or if you had an arbitrarily growing collection of SQLSoup > instances themselves, you would see unbounded growth in class-mapping > artifacts. Nothing is strongly referenced at the module level so even if > you created SQLSoup instances constantly and lost references to them, while > such a scheme would perform horribly and obliterate any advantage gained by > Tornado, it still shouldn't leak memory. > > You might want to peek inside of sqlsoup._cache and see if that is growing > for some reason. > > -- > 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. > -- 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.
