[ZODB-Dev] tid error with ClientStorage cache in Zope 2.9.2

[Tim Peters]

[Tim]
>> No, I don't. The internal docs/comments are inconsistent on this
>> point.  FileCache.settid() starts with
>>
>>     ##
>>     # Update our idea of the most recent tid.

[Chris]
> Is this the most recently used or the most recently available?
> (possible off-by-one error)

Neither, really.  It's the largest tid the ZEO client cache has been
told about.  Cache verification needs to know this, because a ZEO
cache typically _doesn't_ know about all current transactions when it
starts up.  It has to negotiate with the ZEO server to process
invalidations due to transactions with tids larger than the last one
it knew about.  To support this, a persistent ZEO cache stores the
value of the largest tid the ZEO client knew about in the cache file.

...

>> My best guess now is that the setLastTid() comments record the actual
>> intent, and that settid() is overly restrictive here in not allowing
>> equality.  But I don't understand/remember the details of cache
>> verification well enough to be sure.

> In a perfect world, we could change it and see what tests fail.
> I'm not that brave ;-)

Then shame someone else into courage ;-)  I'll bet a dollar no test will fail.

...

> Well, I never saw these errors (which are from a specific check now
> based on a comment which may not have been correct as judged by my
> extremely limited understanding ;-) with Zope 2.7, which is the last
> version of Zope this instance ran on before 2.9...
>
> Dunno if that helps at all :-S

That's comparing a pre-MVCC ZODB to a post-MVCC ZODB, and the ZEO
client cache has little in common between them.  The pre-MVCC ZEO
client cache did no sanity checking on the "last tid" values it saw
over time, so this particular error was impossible in Zope 2.7 -- even
if tids were so pathological that they got smaller over time, a Zope
2.7 ZEO client cache wouldn't complain about that.  A post-MVCC cache
may well complain even if nothing is wrong :-)