On May 29, 2006, at 11:33 AM, Brad Clements wrote:

Or in other words, why can't I use the same code under both plain and
threadlocal?


you can. __del__ and close() are always available in the exact same way regardless of threadlocal status, both return the connection to the pool (in the case of close(), its matched against a counter of how many times it was checked out).

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."

im glad it bothers you, since it is happens to be incorrect, and i have just removed it from the docs in changeset 1549. there is a counter tracking checkouts of the same connection vs. calls to close (). this is the actual behavior (the echo_pool flag used in this test was just fixed in changeset 1549):

>>> from  sqlalchemy import *
>>> e = create_engine('postgres://scott:[EMAIL PROTECTED]/test', echo_pool=True, strategy='threadlocal')
>>> c1 = e.contextual_connect()
[2006-05-29 12:41:23,971] [pool] : Connection <connection object at 0x11c9530; dsn: 'dbname=test host=127.0.0.1 user=scott password=tiger', closed: 0> checked out from pool
>>> c2 = e.contextual_connect()
>>> c1.connection  is c2.connection
True
>>> c1.close()
>>> c2.close()
[2006-05-29 12:41:43,737] [pool] : Connection <connection object at 0x11c9530; dsn: 'dbname=test host=127.0.0.1 user=scott password=tiger', closed: 0> being returned to pool


having the close() method on a result set directly return the underlying connection
to the pool seems very odd and unexpected.


this only happens when you are using implicit executions, which internally is done via:

        c = engine.contextual_connect(close_with_result=True)

so your own Connection objects will never have this flag turned on. it is only used when you say:

        r = table.select().execute()

above, youll notice we didnt get a Connection at all. it was allocated within the call to execute() and we never see it. in SQLAlchemy 0.1, the issue of returning this connection to the pool was handled by waiting for the __del__() method. In 0.2, that mechanism is still in place, but if youd like to explicitly free the resources allocated by this execution because you cant trust __del__ (), you call close() on the result, keeping in mind close() just means "decrement the checkout counter which was incremented when we said 'table.select().execute()'. this wont break any other connections or results in progress since the "open/close" calls are matched by the counter. youll note that "r" is the only handle whatsoever to the resources declared by the execute() call, so it is natural that when "r" is finished, it should free those resources.

"r" will also decrement the connection's checkout counter (i.e. calls close()) when its results are exhausted, which further decreases reliance upon __del__(). There is a Dialect flag which can be enabled for DBAPIs that may have proxied state within their rowsets that will disable this behavior, but none of the current supported DBAPIs seem to have that restriction.

in Hibernate, this is called the "after statement release mode": http://www.hibernate.org/hib_docs/v3/reference/en/html/ transactions.html#transactions-connection-release

I want to use resultset.close() in ALL of my code, so that it will work "correctly"
under either strategy.


go nuts. should all work fine. all the work ive done in this area was designed specifically towards your request for this functionality (obviously, it will be required by others as well).




-------------------------------------------------------
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