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 _______________________________________________ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
