[ZODB-Dev] funky _p_mtime values

[Dieter Maurer]

Thomas Clement Mogensen wrote at 2007-9-27 12:43 +0200:
> ...
>Within the last few days something very strange has happened: All  
>newly created or modified objects get a _p_mtime that is clearly  
>incorrect and too big for DataTime to consider it a valid timestamp.  
>(ie. int(obj._p_mtime) returns a long).
>
>Values I get for _p_mtime on these newly altered objects are  
>something like:
>8078347503.108635
>with only the last few decimals differing among all affected objects.
>Objects changed at the same time appear to get the same stamp.

Looks interesting....

When I see such unexplainable things, I tend to speak of alpha rays....
Computers are quite reliable -- but not completely. Every now
and then a bit is changing which should not change.
In my current life, I have seen things like this 3 times -- usually
in the form that the content of a file changed without that
any application touched it.

When you accept such a wieldy explanation, then, maybe, I can
give one:

  FileStorage must ensure that all transaction ids (they are
  essentially timestamps) are strictly increasing.

  To this end, it maintains a "current transaction id".
  When a new transaction id is needed, it tries to construct
  one from the current time. But if this is smaller than
  the "current transaction id", then it increments that a little
  and uses it as new transaction id.

  Thus, if for some reasons, once a bit changed in the 
  current transaction id (or in the file that maintains it
  persistently), then you may no longer get away with it.

On Plone.org, someone asked today how to fix the
effects on the ZODB of an administrator changing the system time to 2008.
If he finds a solution, then your problem may be tackled the same way.



-- 
Dieter