shane at hathawaymix
Jan 12, 2005, 10:04 PM
Post #3 of 3
(715 views)
Permalink
|
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 [at] zope
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 )
|
