--On 30. Oktober 2005 22:17:44 -0500 Tim Peters <[EMAIL PROTECTED]> wrote:

Second, time-stamp skew doesn't lead to inconsistency.

Fleshing out a bit, ZODB uses time.gmtime() as a starting point, not
necessarily as its final timestamp.  When generating a new tid, if
time.gmtime() is <= the last tid generated, the last tid is incremented
instead (by a small number of nanoseconds).  So tids are always strictly
increasing, no matter how crazy the system clock gets.  Older versions of
ZODB had some obscure bugs in extreme cases of clock insanity, under which
it was possible for tids not to always increase, but no bugs of that sort
should remain.

It's still a bad idea to let the system clock be insane, and upon opening
a FileStorage ZODB logs a warning message if time appears to have "gone
backwards" at all, and a critical message if it appears to have gone
backwards by more than 30 minutes (but note that if the system clock "went
forward" in time, ZODB has no way to guess that).  tids in current ZODBs
will still be increasing, but there's a downside:  there are a _lot_ of
"small number of nanoseconds" in a second, so for as long as ZODB remains
in "increment the last tid by a small number of nanoseconds, because
time.gmtime() is crazy" mode, successive transactions will get timestamps
only a few nanoseconds apart.  This can wreak havoc with, e.g., forensic
analysis of database dumps, and with sane packing (if the last year's
worth of transactions all appear to have occurred in the same 1-second
interval, good luck guessing a useful pack-time argument).

Thanks for this detailed answer!


Attachment: pgpwRC0kPfVDw.pgp
Description: PGP signature

For more information about ZODB, see the ZODB Wiki:

ZODB-Dev mailing list  -  ZODB-Dev@zope.org

Reply via email to