[ZODB-Dev] RE: [Zope-Annce] ZODB 3.2.4 release candidate 1released

[Chris McDonough]

On Tue, 2004-09-14 at 22:02, Chris McDonough wrote:
< about POSKeyError >
> I just wish it didn't subclass KeyError.  Maybe instead of going on a
> sticky jihad I should make a ZODB branch that had a POSKeyError that
> didn't subclass KeyError.  Would it be reasonable to make this change
> for 3.3 or should I just forget it?

... and paranoia overtakes me. ;-)

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

This symptom has in the past been attributable to mutating the items in
a BTree while iterating over a BTreeItems doodad.  But I don't do that
anymore (note the list())  and 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

<waves hands furiously>

- C