Thanks Michael. On 11/15/2012 08:41 PM, Michael Bayer wrote: > that's possible, it's a pretty old, little used, API, and that > document probably assumes GC will pick up on it, and it would be > better if dispose() was called on the pool all the way through. But > the garbage collector should be reclaiming the pool and those > connections (all DBAPIs I'm aware of release TCP/IP connections when > the connection is garbage collected). Even calling gc.collect(), > you're not seeing anything clear out ?
gc.collect() does close the connection iff the closed connection object (well, ConnectionFairy actually in this case) has also gone out of scope or been deleted; but not otherwise. So apparently the ConnectionFairy (even after its closed) still holds references that keep the pool and its connections alive. >> It seems that perhaps _DBProxy is relying on garbage collection to >> somehow clean everything up once it lets go of its reference to >> the pool, but even on CPython with refcounting GC this does not >> seem to work; > > CPython clears unreachable cycles periodically as well. calling > gc.collect() will force this process to occur. Yeah, when I mentioned refcounting I wasn't even thinking of cycle collection, I just meant that CPython is the best-case for reliance on GC, compared to eg pypy, so it's worth having a deterministic way to make sure all the connections are closed. > your best bet for now is to just iterate through db.proxy.pools and > just call dispose() on them. > > http://www.sqlalchemy.org/trac/ticket/2609 is added. Thanks! Carl -- 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 sqlalchemy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en.
