On Wednesday 12 January 2005 12:15 pm, Rodrigo Dias Arruda Senra wrote:
Inside the redefined::open(), the lock is acquired and released before delegating to the original::open(). I wonder if:
1) That was done intentionally as a _step_on_the_break_ measure 2) acquire() or release() cause a desired side effect (despite 1), inside ZODB's inner-sanctum (that eludes me) 3) That was not the original intention, where apply() should come between acquire() and release() 4) none above (I'd appreciate to learn why)
It's intentional. The quick lock and unlock normally has no effect, but while getControlledRefcounts is running, it holds _open_lock for several seconds, preventing new connections. With the lock held, it waits for other connections to close, clears caches, computes the refcounts, and releases _open_lock. It does all this to take refcount measurements in a relatively controlled environment. Like Tim said, open() calls that start before getControlledRefcounts acquires _open_lock will not block. getControlledRefcounts does not account for that, so its call to pools.items() is unreliable. A possible solution is for getControlledRefcounts to also acquire the database's connection pool lock, accessible via the _a and _r attributes. But it can't hold that lock for long, since other threads will need it to close connections. I didn't know anybody still uses LeakFinder. :-) Shane