On 6/25/06, Michael Bayer <[EMAIL PROTECTED]> wrote:
Actually, closer inspection of the stack trace reveals something
interesting: there is one thread where the __del__ method on the
ConnectionFairy is getting called within the get() method of Queue,
and creating a reentrant lockup since __del__ tries to return the
connection to the Pool, calls put() on Queue, and the mutex is
already grabbed by the enclosing get().
Changeset 1657 commits some initialization to change Queue's mutex to
be a threading.RLock, and the two threading.Conditions to derive from
it, so that a put() wtihin a get() wont hang within a single thread.
I think this might be the actual thing going on, although i cannot
reproduce a __del__ getting called just like that. i think 1657
might solve your problem.
this also might be a cue to start thinking about not using
Queue.Queue for the connection pool, since im never a fan of changing
internals like that.
Any suggestions for an alternative?
Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________ Sqlalchemy-users mailing list Sqlalchemy-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sqlalchemy-users
