4.2. Direct use of StateManager

The examples throughout this manual have always derived user classes from LockManager. The reasons for this are twofold. Firstly, and most importantly, the serialisability constraints of atomic actions require it, and secondly it reduces the need for programmer intervention. However, if only access to TxCore's persistence and recovery mechanisms is required, direct derivation of a user class from StateManager is possible.
Classes derived directly from StateManager must make use of its state management mechanisms explicitly (these interactions are normally undertaken by LockManager). From a programmer's point of view this amounts to making appropriate use of the operations activate, deactivate and modified, since StateManager's constructors are effectively identical to those of LockManager.
boolean activate ()
boolean activate (String storeRoot)
Activate loads an object from the object store. The object’s UID must already have been set via the constructor and the object must exist in the store. If the object is successfully read then restore_state is called to build the object in memory. Activate is idempotent so that once an object has been activated further calls are ignored. The parameter represents the root name of the object store to search for the object. A value of null means use the default store.
boolean deactivate ()
boolean deactivate (String storeRoot)
The inverse of activate. First calls save_state to build the compacted image of the object which is then saved in the object store. Objects are only saved if they have been modified since they were activated. The parameter represents the root name of the object store into which the object should be saved. A value of null means use the default store.
void modified ()
Must be called prior to modifying the object in memory. If it is not called the object will not be saved in the object store by deactivate.