Direct Use of StateManager
The examples throughout this manual derive user classes from LockManager. These are two important reasons for this. Firstly, and most importantly, the serializability constraints of atomic actions require it. It reduces the need for programmer intervention. However, if you only require access to TxCore's persistence and recovery mechanisms, 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. Example 4.3. activate 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. Example 4.4. deactivate 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. Example 4.5. modified 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.