the moral of the story is, if "del object" takes the reference count down to zero, but Jython is still not going to call __del__ despite this, then the connection pooling in SA needs some major changes to explicitly count checkouts within the same thread, since the current engine implementation relies upon this (i.e. it cant call close() flat-out without a checkout counter because the connection might still be in use in an enclosing stack frame).
can we confirm that this is the case ? Michael Bayer wrote: > > I should note that the connection pooling mechanism is also binding the > checked-out connection to the current thread, meaning if you are holding > onto the connection (i.e. a connection returned from pool.Pool, which > noone here has probably dealt with directly), and then later on you check > a connection out again, you will get the same connection. the engine uses > this style of connection pool internally to bind multiple nested events in > a single thread to the same connection. > > however, when you ask the SQLEngine explicitly for a new ConnectionProxy > (which is currently a SQLSession), it flips an option to insure that that > particular connection is in fact totally distinct and not bound to the > thread or anything, its yours and yours alone. > > > Brad Clements wrote: >> On 5 Apr 2006 at 17:57, Michael Bayer wrote: >> >>> > Once I'm done with it, how do I release such connection back to >>> > pool so it can be used by other parts of the system? >>> > >>> >>> yes, its unique to you owning it. to release it, you just let go of >>> it. The pooling module works based on the Connection object falling >>> out of scope, which is what will ultimately occur. >> >> Just an interjection.. are you counting on garbage collection as the >> only >> way to >> release the connection? >> >> If so, please add an explicit release method. Someday when Jython is >> capable, >> I'd like to use sqlalchemy on Jython, and you can't count on garbage >> collection >> there. >> >> I believe its better to always at least offer explicit display methods >> than to rely on >> garbage collection for any cleanup. >> >> If I've mis-understood this issue .. never mind! ;-) >> >> >> -- >> Brad Clements, [EMAIL PROTECTED] (315)268-1000 >> http://www.murkworks.com >> AOL-IM or SKYPE: BKClements >> >> >> >> >> ------------------------------------------------------- >> This SF.Net email is sponsored by xPML, a groundbreaking scripting >> language >> that extends applications into web and mobile media. Attend the live >> webcast >> and join the prime developer group breaking into this new coding >> territory! >> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 >> _______________________________________________ >> Sqlalchemy-users mailing list >> Sqlalchemy-users@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/sqlalchemy-users >> > > > > ------------------------------------------------------- > This SF.Net email is sponsored by xPML, a groundbreaking scripting > language > that extends applications into web and mobile media. Attend the live > webcast > and join the prime developer group breaking into this new coding > territory! > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 > _______________________________________________ > Sqlalchemy-users mailing list > Sqlalchemy-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/sqlalchemy-users > ------------------------------------------------------- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 _______________________________________________ Sqlalchemy-users mailing list Sqlalchemy-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sqlalchemy-users
