1.2.4. The life-cycle of a Transactional Object for Java

A persistent object not in use is assumed to be held in a passive state with its state residing in an object store and activated on demand. The fundamental life cycle of a persistent object in TXOJ is shown in figure 2.
Figure 2: The lifecycle of a persistent object.
  • The object is initially passive, and is stored in the object store as an instance of the class OutputObjectState.
  • When required by an application the object is automatically activated by reading it from the store using a read_committed operation and is then converted from an InputObjectState instance into a fully-fledged object by the restore_state operation of the object.
  • When the application has finished with the object it is deactivated by converting it back into an OutputObjectState instance using the save_state operation, and is then stored back into the object store as a shadow copy using write_uncommitted. This shadow copy can be committed, overwriting the previous version, using the commit_state operation. The existence of shadow copies is normally hidden from the programmer by the transaction system. Object de-activation normally only occurs when the top-level transaction within which the object was activated commits.


During its life time, a persistent object may be made active then passive many times.