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

Reply via email to