- changed status to resolved
connection pool needs to use checkout/checking counting - ResultProxy will require a close() method
the jython folks dont have such a reliable implementation of __del__
, and even if they did I can already tell people's mistrust on this one is going to make this inevitable. while __del__
should remain as one way for connections to get returned to the pool, additionally add a counter to ConnectionFairy
, have Pool
increment the counter when giving out a connection and have ConnectionFairy
decrement it when the close() method is called, then return to the pool when the counter hits zero.
so if things have been working for you with __del__
, theyll still work; but your app might not be very good in a Jython environment.
Basically ResultProxy
will have to enforce a close() method. The alternative, doing it automatically, would mean doing a close() on the last iteration, meaning the RowProxy
's it returns cant point to a "live" row and it would have to be copied into a buffer, at which point i definitely dont want to do that (i.e. add huge overhead to workaround an issue smaller than the overhead itself).
more tricky is a CRUD operation. Assuming you cant rely upon __del__
, youll now have to close() the result from an insert/update/delete:
r = table.update().execute()
r.close()
if you are using explicit connections, i.e. these two not-yet-released styles:
table.update().using(conn).execute()
conn.execute(table.update())
then you can obviously just close the connection object you retrieved.
note that mapper operations process results fully, so the close() method will just be added internally to mapper methods and wont affect their usage.
additionally, SQLEngine will have to internally become connection aware...SchemaIterator
objects will have to pull their own connection out, hold onto it, and then have the SchemaIterator
be closed at the end of the operation. this also had to be added to various scalar() operations, default function executes, etc. the unittest suite should be enhanced to disable the Pool
's __del__
functionality, run the entire suite, and verify that connection counters operate properly...probably best acheived via a ConnectionFairy
wrapper.
Comments (1)
-
reporter - Log in to comment
this is repaired in the 0.2 branch.