On 27 May 2006 at 20:36, Michael Bayer wrote: > sure, right here: > > http://www.sqlalchemy.org/docs/dbengine.myt#dbengine_connections_conte > xt > > just switch on 'create_engine('foo', strategy="threadlocal")' and > youve got identical 0.1 behavior.
with respect to __del__ vs close() on result sets and stuff. It seems to me that tying connection pool policy (thread shared "threadlocal" vs implicit "plain") with result disposal is not clean. The threading model used probably depends on the deployment environment, which in turn should not effect how I treat result sets. Or in other words, why can't I use the same code under both plain and threadlocal? In our previous conversation about jython and __del__, I thought the resultion was that __del__ just calls close(), and that close() can be called multiple times (after the first time, it's ignored). It would certainly be ideal that I could use the same code under either threading model. But this comment from the above URL really bothers me: "While the close() method is still available with the "threadlocal" strategy, it should be used carefully. Above, if we issued a close() call on r1, and then tried to further work with results from r2, r2 would be in an invalid state since its connection was already returned to the pool. By relying on __del__() to automatically clean up resources, this condition will never occur." I'd expect the close() method on a result set to close the cursor, and when the last cursor on a threadlocal connection is closed, then connection will be returned to the pool. having the close() method on a result set directly return the underlying connection to the pool seems very odd and unexpected. Also, its no longer possible to write code that works under either strategy, because in one I'd use close() as a nicety but in the other strategy that code would break. I want to use resultset.close() in ALL of my code, so that it will work "correctly" under either strategy. I'd never expect that closing a resultset would cause the engine to be released. Shouldn't the threadlocal engine be retained until all child resultsets have been closed, THEN it should be released to the pool.. ? -- Brad Clements, [EMAIL PROTECTED] (315)268-1000 http://www.murkworks.com AOL-IM or SKYPE: BKClements ------------------------------------------------------- All the advantages of Linux Managed Hosting--Without the Cost and Risk! Fully trained technicians. The highest number of Red Hat certifications in the hosting industry. Fanatical Support. Click to learn more http://sel.as-us.falkag.net/sel?cmd=lnk&kid=107521&bid=248729&dat=121642 _______________________________________________ Sqlalchemy-users mailing list Sqlalchemy-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sqlalchemy-users
