--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! Andreas
pgpwRC0kPfVDw.pgp
Description: PGP signature
_______________________________________________ For more information about ZODB, see the ZODB Wiki: http://www.zope.org/Wikis/ZODB/ ZODB-Dev mailing list - ZODB-Dev@zope.org http://mail.zope.org/mailman/listinfo/zodb-dev
