Ce contenu n'est pas disponible dans la langue sélectionnée.

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);
};
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;
    }
}
Copy to Clipboard Toggle word wrap
Retour au début
Red Hat logoGithubredditYoutubeTwitter

Apprendre

Essayez, achetez et vendez

Communautés

À propos de la documentation Red Hat

Nous aidons les utilisateurs de Red Hat à innover et à atteindre leurs objectifs grâce à nos produits et services avec un contenu auquel ils peuvent faire confiance. Découvrez nos récentes mises à jour.

Rendre l’open source plus inclusif

Red Hat s'engage à remplacer le langage problématique dans notre code, notre documentation et nos propriétés Web. Pour plus de détails, consultez le Blog Red Hat.

À propos de Red Hat

Nous proposons des solutions renforcées qui facilitent le travail des entreprises sur plusieurs plates-formes et environnements, du centre de données central à la périphérie du réseau.

Theme

© 2026 Red Hat