[ZODB-Dev] More exciting ZODB errors ;-)

[Tim Peters]

[Timmy]
>> Jeremy, the code at the start of _setstate() looks fishy:  any idea what
>> the intent was?:
>>
>>         # There is a harmless data race with self._invalidated.  A
>>         # dict update could go on in another thread, but we don't care
>>         # because we have to check again after the load anyway.
>>
>>         if (obj._p_oid in self._invalidated
>>             and not myhasattr(obj, "_p_independent")
>>             and not self._invalidated
>>             ):
>>             # If the object has _p_independent(), we will handle it
below.
>>             self._load_before_or_conflict(obj)
>>             return

[Jeremy]
> I don't have any idea what the intent of "not self._invalidated" was. I
> looked back at 3.3a2, which I think was the first MVCC release.  It
> doesn't have the "and not self._invalidated" line , and I can't think of
> why it would.  The code is just an optimization; it's trying to avoid
> loading the current version if it knows that it needs a non-current
> version.
>
> I don't have a checkout of ZODB, so I can't check the svn blame.  Does it
> say who wrote the code and what change it was related to?

Congratulations on weaseling out of another one ;-)!  Turns out this all
happened after your statutory blame period, as part of a large merge to fix
ZClasses:

<http://svn.zope.org/ZODB/branches/3.4/src/ZODB/Connection.py?rev=29891&view
=rev>

That introduced the "and not self._invalidated" clause.  We'll fix that one
way or another (it doesn't make sense), but I'm pretty sure it's irrelevant
to Chris's symptom (it stops an optimization rather than creates a problem).