>> It's actually that the number of __del__-resurrecting objects *plus*
>> the number of non-ghostifiable objects in cache is larger than the
>> cache target size, right?

[Mario Lorenz]
> Yes, but when you push the minimize button, the cache target size is
> 0.

That would do it <wink>.

> Nonwithstanding our code (it was mostly debugging/tracing
> functionality anyway, so it was easy to fix),

I'm glad to hear that!

> it is just that with Zope 2.5, it seemed to work (at least I never
> got a bug report back then) so it took us a while to track this down.

I expect that in your Zope 2.5 installation, the cache was implemented in a
very different way.  The current implementation is universally regarded as a
major improvement.  Maybe Toby remembers which release(s) of ZODB the
current cache implementation first appeared in; it's not brand new, but is
relatively recent.

> Especially since we had just moved to RHEL3, so we were expecting
> more like a threading issue...

Be patient <wink>.

> Given that this property is not that widely published (in the various
> tutorials etc.),

I believe the idea that a persistent object with a __del__ method could
provoke an infinite loop in cPickleCache was news to all of us, and yours
was the first report.

> I wonder if it might be a good idea to improve that loop check code,
> and walk through the ring not more than once, using a counter, and
> not the comparison vs. the ring start, which, as we have seen, may
> be a target that moves too quickly.

We need to open Collector issues for ZODB bugs and patches, because they
have a history of getting lost sometimes when confined to the mailing list.
I opened an issue for this one here:


Zope-Dev maillist  -  [EMAIL PROTECTED]
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope )

Reply via email to