[ZODB-Dev] More exciting ZODB errors ;-)
Tim Peters
tim at zope.com
Wed Dec 14 13:26:45 EST 2005
[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).
More information about the ZODB-Dev
mailing list