Motorola 6806800C47B Manual De Usuario

Descargar
Página de 26
1
Checkpoint Service Programmer’s Reference (6806800C47B)
13
   
Introduction
1.1
Overview
The Checkpoint Service provides a facility for processes to record checkpoint data 
incrementally, which can be used to protect an application against failures. When recovering 
from fail-over or switch-over situations, or restart situations, the checkpoint data can be 
retrieved, and execution can be resumed from the state recorded before the failure. 
Checkpoints are cluster-wide entities that are designated by unique names. A copy of the data 
stored in a checkpoint is called a checkpoint replica, which is stored in the main memory rather 
than on disk for performance reasons. A given checkpoint may have several checkpoint replicas 
stored on different nodes in the cluster to protect it against node failures.To avoid accumulation 
of unused checkpoints in the system, checkpoints have a retention time. When a checkpoint has 
not been opened by any process for the duration of the retention time, the Checkpoint Service 
automatically deletes the checkpoint.
The CPSv service supports the following two types of update options:
z
Asynchronous update option
z
Synchronous update option
In the case of asynchronous update option, one of the replicas is designated as the active 
replica. Data is always read from the active replica and there is no guarantee that all the other 
replicas contain identical data. A write call returns after updating the active replica. 
In the case of synchronous update options the call invoked to write to the replicas returns only 
when all replicas have been updated, i.e. either all replicas are updated or the call fails and no 
changes are made to the replicas. 
The CPSv supports both collocated and non-collocated checkpoints. In case of checkpoints 
opened with collocated and asynchronous update option, it is up to the application to set a 
checkpoint to the active state. In all other cases the CPSv itself handles which checkpoint is 
currently active.
The CPSv defined by SAF does not support hot-standby. This means that the currently stand-
by component is not notified of any changes made to the checkpoint. When the stand-by 
component gets active, it has to iterate through the respective checkpoint sections to get up-to-
date. To overcome this drawback, the CPSv provides additional, non-SAF APIs which help to 
notify the stand-by component of changes and thus facilitate the implementation of a hot-stand-
by.