Jim Fulton wrote at 2008-9-30 18:30 -0400:
>>> c. Close the file storage, causing subsequent reads and writes to
>> Raise an easily recognizable exception.
>I raise the original exception.
The original exception may have many consequences -- most probably
harmless. The special exception would express that the consequence was
>> In our error handling we look out for some nasty exceptions and
>> a restart in such cases. The exception above might be such a nasty
>The critical log entry should be easy enough to spot.
For humans, but I had in mind that software recognizes the exception
automatically and forces a restart.
Or do you have a logger customization in mind that intercepts the
log entry and then forces a restart?
In may not be trivial to get this right (in a way such that
the log entry does appear in the logfile before the restart starts).
>>> - Have a storage server restart when a tpc_finish call fails. This
>>> would work fine for FileStorage, but might be the wrong thing to do
>>> for another storage. The server can't know.
>> Why do you think that a failing "tpc_finish" is less critical
>> for some other kind of storage?
>It's not a question of criticality. It's a question of whether a
>restart will fix the problem. I happen to know that a file storage
>would be in a reasonable state after a restart. I don't know this to
>be the case for some other storage.
But what should an administrator do when this is not the case?
Either a stop or a restart....
It may well be that a restart *may* not lead into a fully functional
state (though this would indicate a storage bug) but a definitely not
working system is not much better than one that may potentially not
be fully functional but usually will be apart from storage bugs.
For more information about ZODB, see the ZODB Wiki:
ZODB-Dev mailing list - ZODB-Dev@zope.org