[ZODB-Dev] RE: [Zope-Annce] ZODB 3.2.4 release candidate 1released
Dieter Maurer
dieter at handshake.de
Wed Sep 15 14:13:43 EDT 2004
Chris McDonough wrote at 2004-9-15 02:29 -0400:
> ...
>I'm trying to figure out a reported error case for Transience that
>involves a problem that manifests itself in a symptom like this:
>
>>> iobtree = IOBTree()
>>> iobtree[1] = 1
>>> iobtree[2] = 2
>>> keys = list(iobtree.keys(None, 100))
>>> for key in keys:
>>> del iobtree[key]
>KeyError: 1
> ...
>I'm wondering if this sounds like a
>plausible series of events under Zope-2.7.2 + its version of ZODB that
>might explain it:
>
>- a reference to a soon-to-be-unreachable object is created
> via the "pending modifications in subtransactions reused
> from cache when txn not committed or aborted" bug. This
> object is referenced in a leaf node by a bucket of an
> IOBTree and its key is also kept by the IOBTree itself in
> its interior node structure.
>
>- the unreachable object is eventually ghosted in some thread
>
>- The IOBTree's keys() method is called. It returns what it thinks
> is the set of keys it has.
>
>- The set of keys is iterated over and __delitem__ is called on
> the BTree with each key. When it reaches the ghosted object and
> tries to unghost it, a POSKeyError is generated. (does it *need*
> to unghost it?)
>
>- Whatever code implements __delitem__ on a BTree catches the
> POSKeyError and reraises it as a KeyError
I checked the BTrees code: it does not catch "POSKeyError" (and convert it
into "KeyError"). The relevant code is in fact in the macro
"PER_USE_OR_RETURN", defined in "ZODB.cPersistence.h".
--
Dieter
More information about the ZODB-Dev
mailing list