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

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

Copy to Clipboard

Toggle word wrap

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 
	    ...
	}
	}

public boolean op1 (...)
{	
    if (setlock (new Lock(LockMode.WRITE) == LockResult.GRANTED)
	{
	    // actual state change operations follow 
	    ...
	}
	}

Copy to Clipboard

Toggle word wrap

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 operation activate, which loads, if not done already, the latest persistent state of O from the object store. Then call the StateManager operation modified, which creates an instance of either RecoveryRecord or PersistenceRecord for O, depending upon whether O is persistent or not, and inserts it into the RecordList of Trans.
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.

トップに戻る

このコンテンツは選択した言語では利用できません。

9.2.8. The Class Hierarchy

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

多様性を受け入れるオープンソースの強化

会社概要

Theme

Red Hat legal and privacy links

Red Hat legal and privacy links