The reason I wrote PooledConnection the way I did was so that existing code
could be ported easily, and the close statement would still do something. I
tried the __del__ method, but it's not entirely reliable. Objects apparently
don't get __del__'ed as soon as they go out of scope (as I had hoped) so:
class1 = X()
class2 = X()
print "Class2 should close now:"
print "Class1 should close now:"
actually prints this:
Class2 should close now:
Class1 should close now:
So garbage collection isn't happening at the end of the while loop, as I had
hoped it would.
But since your class works exactly like mine does, with the added bonus of
eventual cleanup, I certainly don't see anything wrong with it.
Can this still make it into the MiddleKit for 0.4, or should it wait for a
--- Geoff Talvola <gtalvola@...> wrote:
> Wow, this db connection pooling stuff is easier than I thought. I love
> Python. Let's get something like this
> into WebWare.
> I think PooledConnection should look something like this, to make the
> non-threadsafe version work properly (my
> modifications marked with ###):
> class PooledConnection:
> def __init__(self, pool, db):
> self.db = db
> self.pool = pool
> def close(self):
> if self.db != None: ###
> print "closing..." ###
> self.pool.returnConnection(self.db) ###
> self.db = None ###
> def __getattr__(self, name):
> return getattr(self.db, name)
> def __del__(self): ###
> self.close() ###
> This might be a dumb question, but if the db module is thread-safe, and you
> can use the same connection in
> multiple threads with no problems, why have a connection pool at all? Why
> not just share one connection across
> all threads? I'm guessing it's because the db module contains locking code
> to that only one thread can actually
> use the connection at a time, am I right?
> - Geoff Talvola
> Parlance Corporation
> Webware-discuss mailing list
Do You Yahoo!?
Yahoo! Mail - Free email you can access from anywhere!