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
