[ZODB-Dev] RE: Re: "Time travel" conflict errors in Zope

[Tim Peters]

[Jeremy Hylton]
> If you restart the ZEO client to refresh its cache, you will probably
> take the fast path through the cache verification where the server sends
> a list of modified objects to the server.
                                    ^^^^^^
                                    client

> If the client saw transaction T1 and failed to invalidate the objects
> it modified

That's supposed to be impossible, isn't it?

> or if the client missed T1 and saw a later transaction T2,

Ditto.

> then the fast path code would not resend invalidations for T1.

Sure, but how could the preconditions trigger?

> Rather than adding extra complexity to the cache verification, it does
> seem expedient to delete the cache file and restart.

If

    the client saw transaction T1 and failed to invalidate the objects
    it modified

or

    the client missed T1 and saw a later transaction T2

then wouldn't we be looking at a non-verification bug?  In which case, ya,
it might be nice if verification detected it, but it seems there's a fatal
problem that should be detected regardless of whether verification happens
to run.

It may be relevant that ClientStorage.invalidateTransaction() sets the last
tid *before* it processes invalidations, although I'm not sure how, since
the cache files don't appear to change size during invalidation.  I suppose
the log file could trigger "disk full" then if invalidation tried to record
an error, and that could leave the client cache's idea of its last tid out
of synch with the cache invalidations actually completed.