[ZODB-Dev] What's best to do when there is a failure in the second phase of 2-phase commit on a storage server

[Dieter Maurer]

Jim Fulton wrote at 2008-9-30 18:30 -0400:
> ...
>>>  c. Close the file storage, causing subsequent reads and writes to
>>> fail.
>>
>> Raise an easily recognizable exception.
>
>I raise the original exception.

Sad.

The original exception may have many consequences -- most probably
harmless. The special exception would express that the consequence was
very harmfull.

>> In our error handling we look out for some nasty exceptions and  
>> enforce
>> a restart in such cases. The exception above might be such a nasty
>> exception.
>
>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.



-- 
Dieter