9.2.3. Recovery and persistence

The StateManager class is at the root of the class hierarchy, and is responsible for object activation and deactivation and object recovery. See Example 9.1, “StateManager Implementation”.

Example 9.1. StateManager Implementation

public abstract class StateManager
{
public boolean activate ();
public boolean deactivate (boolean commit);

public Uid get_uid (); // object’s identifier.

// methods to be provided by a derived class

public boolean restore_state (InputObjectState os);
public boolean save_state (OutputObjectState os);

protected StateManager ();
protected StateManager (Uid id);
};

public abstract class StateManager
{
public boolean activate ();
public boolean deactivate (boolean commit);

public Uid get_uid (); // object’s identifier.

// methods to be provided by a derived class

public boolean restore_state (InputObjectState os);
public boolean save_state (OutputObjectState os);

protected StateManager ();
protected StateManager (Uid id);
};

Copy to Clipboard

Toggle word wrap

Objects can be classified as recoverable, recoverable and persistent, or neither recoverable nor persistent.

Recoverable: StateManager attempts to generate and maintain appropriate recovery information for the object. The lifetimes of such objects do not exceed the application that created them.
Recoverable and Persistent: The lifetime of the object is greater than that of the creating or accessing application. In addition to maintaining recovery information, StateManager attempts to automatically load or unload any existing persistent state for the object by calling the activate or deactivate operation at the appropriate times.
Neither Recoverable Nor Persistent: No recovery information is ever kept nor is object activation or deactivation ever automatically attempted.

If an object is recoverable or recoverable and persistent, then StateManager invokes the save_state method, as part of performing the deactivate method, and the restore_state, as part of performing the activate, at various points during the execution of the application. The programmer must implement these methods, since StateManager cannot detect user-level state changes. The programmer decides which parts of an object’s state should be made persistent. For example, in the case of a spreadsheet, you may not need to save all entries if some values can be recomputed instead. The Example 9.2, “save_state Example” example shows the save_state implementation for a class Example that has integer member variables called A, B and C.

Example 9.2. save_state Example

public boolean save_state(OutputObjectState o)
{
    if (!super.save_state(o))
	return false;
      
    try
	{
	    o.packInt(A);
	    o.packInt(B);
	    o.packInt(C));
}
catch (Exception e)
    {
	return false;
    }
      
return true;
}

public boolean save_state(OutputObjectState o)
{
    if (!super.save_state(o))
	return false;
      
    try
	{
	    o.packInt(A);
	    o.packInt(B);
	    o.packInt(C));
}
catch (Exception e)
    {
	return false;
    }
      
return true;
}

Copy to Clipboard

Toggle word wrap

Note

All save_state and restore_state methods need to call super.save_state and super.restore_state, to take advantage of improvements in the crash recovery mechanisms.

Voltar ao topo

Este conteúdo não está disponível no idioma selecionado.

9.2.3. Recovery and persistence

Aprender

Experimente, compre e venda

Comunidades

Sobre a documentação da Red Hat

Tornando o open source mais inclusivo

Sobre a Red Hat

Theme

Red Hat legal and privacy links

Red Hat legal and privacy links