> Just been digging some more on this issue and found:
> In every case I get this error, the tid's are equal, which suggests your
> notes about the <= potentially being bad were correct ;-)
> I'm low on fu here, so what's the problem with the two tid's being the
> same and do you have any idea why this could be occuring in production
> code on Zope 2.9.x?
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. This is stored in the
# instance, and also written out near the start of the cache file. The
# new tid must be strictly greater than our current idea of the most
# recent tid.
def settid(self, tid):
and that comment matches the code you've seen failing. OTOH, this is
# Set the last transaction seen by the cache.
# @param tid a transaction id
# @exception ValueError attempt to set a new tid less than the current tid
def setLastTid(self, tid):
The coments there say it's an error only if the new tid is < the
current tid, which is most reasonably taken to mean "strictly less".
That doesn't match the code wrt behavior when the tids are equal.
The only other report of your traceback I'm aware of is part of this
confused bug report, in its Comment #4:
That's also complaining about a "new" tid exactly equal to the
"previous" tid during verification.
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.
The patch you found was me changing settid()'s code to match
settid()'s comments and the text of settid()'s error message. I doubt
I noticed that those comments and the error message disagreed with
setLastTid()'s comments at the time, and expected Jeremy to complain
if he thought the change was wrong. He still can, if he remembers the
For more information about ZODB, see the ZODB Wiki:
ZODB-Dev mailing list - ZODB-Dev@zope.org