tasks unable to recover due to the logging failure. Further advantages are simple
recovery as failures do only affect the processes that fail and as no orphans can
occur, recovery always recreates the state just before the failure happened which is
extremely useful in real-life applications [46].
Garbage collection of old messages and recovery points is also easy as all
recovery point except the last can be recycled.
Optimistic logging stores messages mostly asynchronously (in parallel) to the
message delivery and are based on the optimistic assumption that the logging has
finished before a failure occurs. This approach is obviously not suitable for
safety-critical systems where it is assumed that failures occur anytime. In contrast to
the pessimistic approach, simplicity and speed in case of failure are traded to performance in the failure-free case with considerable more complex failure handling.
To keep the logging performance impact small, the determinants are usually
stored in volatile memory (RAM) and periodically flushed to disk. In case of a
failure, the log in volatile memory is lost and a full message replay is not possible.
If the process sent a message to another thread during the not recoverable process
execution, the receiver of the message becomes an orphan and must be rolled back
as well to restore consistency.
Such a rollback might go beyond the last recovery point, which means that
several recovery points are needed. It’s obvious that this recovery considerable
complicates garbage collection of determinants and recovery points.
The necessary information to assert consistency is usually recorded together with
the determinants during failure-free operation.
Optimistic logging allows synchronous and asynchronous recovery; an example
of the former is [47] and for the latter is [31].
Causal logging approach attempts to combine the advantages of the pessimistic
and optimistic loggings [32, 35]. Logging is performed asynchronously (optimistic), i.e., using volatile storage for message logging and persistent storage for the
recovery points and the message log. The volatile message log is flushed to stable
storage before a message is sent to the outside world (output commit). Orphans are
omitted by ensuring that all casual determinants are either stored on disks or are
local to the respective task.
Causality is defined by Lamport’s happened-before [48] relationship. The
locality of determinants is now achieved by piggybacking them on messages sent to
other threads. The advantages of causal logging are traded in for a more complex
recovery protocol.
8.2.4 Other Approaches
There are other approaches, which do not belong to the above presented categories.
Brown [49] uses dedicated machines that snoop the inter-process communication
and store the information to restart the tasks in case of a failure. This approach is
120
8 Recovery Preparation
recovery as failures do only affect the processes that fail and as no orphans can
occur, recovery always recreates the state just before the failure happened which is
extremely useful in real-life applications [46].
Garbage collection of old messages and recovery points is also easy as all
recovery point except the last can be recycled.
Optimistic logging stores messages mostly asynchronously (in parallel) to the
message delivery and are based on the optimistic assumption that the logging has
finished before a failure occurs. This approach is obviously not suitable for
safety-critical systems where it is assumed that failures occur anytime. In contrast to
the pessimistic approach, simplicity and speed in case of failure are traded to performance in the failure-free case with considerable more complex failure handling.
To keep the logging performance impact small, the determinants are usually
stored in volatile memory (RAM) and periodically flushed to disk. In case of a
failure, the log in volatile memory is lost and a full message replay is not possible.
If the process sent a message to another thread during the not recoverable process
execution, the receiver of the message becomes an orphan and must be rolled back
as well to restore consistency.
Such a rollback might go beyond the last recovery point, which means that
several recovery points are needed. It’s obvious that this recovery considerable
complicates garbage collection of determinants and recovery points.
The necessary information to assert consistency is usually recorded together with
the determinants during failure-free operation.
Optimistic logging allows synchronous and asynchronous recovery; an example
of the former is [47] and for the latter is [31].
Causal logging approach attempts to combine the advantages of the pessimistic
and optimistic loggings [32, 35]. Logging is performed asynchronously (optimistic), i.e., using volatile storage for message logging and persistent storage for the
recovery points and the message log. The volatile message log is flushed to stable
storage before a message is sent to the outside world (output commit). Orphans are
omitted by ensuring that all casual determinants are either stored on disks or are
local to the respective task.
Causality is defined by Lamport’s happened-before [48] relationship. The
locality of determinants is now achieved by piggybacking them on messages sent to
other threads. The advantages of causal logging are traded in for a more complex
recovery protocol.
8.2.4 Other Approaches
There are other approaches, which do not belong to the above presented categories.
Brown [49] uses dedicated machines that snoop the inter-process communication
and store the information to restart the tasks in case of a failure. This approach is
120
8 Recovery Preparation