-
Language:
English
-
Language:
English
Red Hat Training
A Red Hat training course is available for JBoss Enterprise Application Platform Common Criteria Certification
9.2.8. The Class Hierarchy
The principal classes which make up the class hierarchy of JBoss Transaction Service are depicted in Example 9.5, “JBoss Transaction Service Class Hierarchy”.
Example 9.5. JBoss Transaction Service Class Hierarchy
StateManager // Basic naming, persistence and recovery control LockManager // Basic two-phase locking concurrency control service User-Defined Classes Lock // Standard lock type for multiple readers/single writer User-Defined Lock Classes AbstractRecord // Important utility class, similar to Resource RecoveryRecord // handles object recovery LockRecord // handles object locking RecordList // Intentions list other management record types AtomicAction // Implements transaction control abstraction TopLevelTransaction Input/OutputBuffer // Architecture neutral representation of an objects’ state Input/OutputObjectState // Convenient interface to Buffer ObjectStore // Interface to the object storage services
Programmers of fault-tolerant applications need the
LockManager
, Lock
and AtomicAction
classes. Other classes important to a programmer are Uid
, and ObjectState
. Most JBoss Transaction Service classes are derived from the base class StateManager
, which provides primitive facilities necessary for managing persistent and recoverable objects. These facilities include support for the activation and deactivation of objects, and state-based object recovery. The class LockManager
uses the facilities of StateManager
and Lock
to provide the concurrency control required for implementing the serializability property of atomic actions. The implementation of atomic action facilities is supported by AtomicAction
and TopLevelTransaction
.
Consider a simple example. Assume that
Example
is a user-defined persistent class suitably derived from the LockManager
. An application containing an atomic transaction Trans accesses an object (called O) of type Example
by invoking the operation op1 which involves state changes to O. The serialisability property requires that a write lock must be acquired on O before it is modified; thus the body of op1 should contain a call to the setlock
operation of the concurrency controller:
public boolean op1 (...) { if (setlock (new Lock(LockMode.WRITE) == LockResult.GRANTED) { // actual state change operations follow ... } }
The
setlock
method, provided by the LockManager
class, performs the following functions in this case:
- Check write lock compatibility with the currently held locks, and if allowed:
- Call the
StateManager
operationactivate
, which loads, if not done already, the latest persistent state of O from the object store. Then call theStateManager
operationmodified
, which creates an instance of eitherRecoveryRecord
orPersistenceRecord
for O, depending upon whether O is persistent or not, and inserts it into theRecordList
ofTrans
. - Create and insert a LockRecord instance in the RecordList of Trans.
If
Trans
is aborted some time after the lock has been acquired, the rollback
operation of AtomicAction
processes the RecordList
instance associated with Trans
by invoking an appropriate Abort
operation on the various records. The implementation of this operation by the LockRecord
class releases the WRITE
lock while that of RecoveryRecord
/PersistenceRecord
restores the prior state of O.
All of the above work is automatically being performed by JBoss Transaction Service on behalf of the application programmer. The programmer only starts the transaction and sets an appropriate lock. JBoss Transaction Service and Transactional Objects for Java take care of participant registration, persistence, concurrency control and recovery.