9.2.5. The Concurrency Controller

The concurrency controller is implemented by the LockManager class, which provides sensible default behavior which the programmer can override if necessary, by the particular semantics of the class being programmed. As with the StateManager class and persistence, concurrency control implementations are accessed through interfaces. The current implementations of concurrency control available to interfaces include:

Access to remote services
Both local disk and database implementations, where locks are written to the local file system or database to make them persistent.
A purely local implementation, where locks are maintained within the memory of the virtual machine which created them. This implementation performs better than writing locks to the local disk, but objects cannot be shared between virtual machines. Importantly, it is a basic Java object with no requirements which can be affected by the SecurityManager

The primary API to the concurrency controller is via the setlock operation. By default, the runtime system enforces strict two-phase locking following a multiple reader, single writer policy on a per object basis. However, as shown in Figure 9.1, “JBoss Transaction Service Class Hierarchy”, by inheriting from the Lock class, programmers can provide their own lock implementations with different lock conflict rules to enable type specific concurrency control.

Lock acquisition is, of necessity, under programmer control. Just as StateManager cannot determine if an operation modifies an object, LockManager cannot determine if an operation needs a read or write lock. Lock release, however, is under control of the system and requires no further intervention by the programmer. This ensures that the two-phase property can be correctly maintained.

public abstract class LockManager extends StateManager
{
    public LockResult setlock (Lock toSet, int retry, int timeout);
};

public abstract class LockManager extends StateManager
{
    public LockResult setlock (Lock toSet, int retry, int timeout);
};

Copy to Clipboard

Toggle word wrap

The LockManager class manages requests to set or release a lock on an object as appropriate. Since it is derived from the StateManager class, it can also control when some of the inherited facilities are invoked. For example, LockManager assumes that the setting of a write lock implies that the invoking operation must be about to modify the object, and may trigger the saving of recovery information if the object is recoverable. In a similar fashion, successful lock acquisition causes activate to be invoked.

Example 9.3. Trying to Obtain A Write Lock

public class Example extends LockManager
{
    public boolean foobar ()
    {
	AtomicAction A = new AtomicAction;
	boolean result = false;
      
	A.begin();
      
	if (setlock(new Lock(LockMode.WRITE), 0) == Lock.GRANTED)
	    {
		/*
		 * Do some work, and TXOJ will
		 * guarantee ACID properties.
		 */
      
		// automatically aborts if fails
      
		if (A.commit() == AtomicAction.COMMITTED)
		    {
			result = true;
		    }
	    }
	else
	    A.rollback();
      
	return result;
    }
}

public class Example extends LockManager
{
    public boolean foobar ()
    {
	AtomicAction A = new AtomicAction;
	boolean result = false;
      
	A.begin();
      
	if (setlock(new Lock(LockMode.WRITE), 0) == Lock.GRANTED)
	    {
		/*
		 * Do some work, and TXOJ will
		 * guarantee ACID properties.
		 */
      
		// automatically aborts if fails
      
		if (A.commit() == AtomicAction.COMMITTED)
		    {
			result = true;
		    }
	    }
	else
	    A.rollback();
      
	return result;
    }
}

Copy to Clipboard

Toggle word wrap

맨 위로 이동

이 콘텐츠는 선택한 언어로 제공되지 않습니다.

9.2.5. The Concurrency Controller

자세한 정보

평가판, 구매 및 판매

커뮤니티

Red Hat 문서 정보

보다 포괄적 수용을 위한 오픈 소스 용어 교체

Red Hat 소개

Theme

Red Hat legal and privacy links

Red Hat legal and privacy links