14.3. Locking Types
14.3.1. About Optimistic Locking
Optimistic locking allows multiple transactions to complete simultaneously by deferring lock acquisition to the transaction prepare time.
Optimistic mode assumes that multiple transactions can complete without conflict. It is ideal where there is little contention between multiple transactions running concurrently, as transactions can commit without waiting for other transaction locks to clear. With
writeSkewCheck enabled, transactions in optimistic locking mode roll back if one or more conflicting modifications are made to the data before the transaction completes.
14.3.2. About Pessimistic Locking
Pessimistic locking is also known as eager locking.
Pessimistic locking prevents more than one transaction to modify a value of a key by enforcing cluster-wide locks on each write operation. Locks are only released once the transaction is completed either through committing or being rolled back.
Pessimistic mode is used where a high contention on keys is occurring, resulting in inefficiencies and unexpected roll back operations.
14.3.3. Pessimistic Locking Types
Red Hat JBoss Data Grid includes explicit pessimistic locking and implicit pessimistic locking:
- Explicit Pessimistic Locking, which uses the JBoss Data Grid Lock API to allow cache users to explicitly lock cache keys for the duration of a transaction. The Lock call attempts to obtain locks on specified cache keys across all nodes in a cluster. This attempt either fails or succeeds for all specified cache keys. All locks are released during the commit or rollback phase.
- Implicit Pessimistic Locking ensures that cache keys are locked in the background as they are accessed for modification operations. Using Implicit Pessimistic Locking causes JBoss Data Grid to check and ensure that cache keys are locked locally for each modification operation. Discovering unlocked cache keys causes JBoss Data Grid to request a cluster-wide lock to acquire a lock on the unlocked cache key.
14.3.4. Explicit Pessimistic Locking Example
The following is an example of explicit pessimistic locking that depicts a transaction that runs on one of the cache nodes:
Procedure 14.3. Transaction with Explicit Pessimistic Locking
tx.begin() cache.lock(K) cache.put(K,V5) tx.commit()
- When the line
cache.lock(K)executes, a cluster-wide lock is acquired onK. - When the line
cache.put(K,V5)executes, it guarantees success. - When the line
tx.commit()executes, the locks held for this process are released.
14.3.5. Implicit Pessimistic Locking Example
An example of implicit pessimistic locking using a transaction that runs on one of the cache nodes is as follows:
Procedure 14.4. Transaction with Implicit Pessimistic locking
tx.begin() cache.put(K,V) cache.put(K2,V2) cache.put(K,V5) tx.commit()
- When the line
cache.put(K,V)executes, a cluster-wide lock is acquired onK. - When the line
cache.put(K2,V2)executes, a cluster-wide lock is acquired onK2. - When the line
cache.put(K,V5)executes, the lock acquisition is non operational because a cluster-wide lock forKhas been previously acquired. Theputoperation will still occur. - When the line
tx.commit()executes, all locks held for this transaction are released.
14.3.6. Configure Locking Mode (Remote Client-Server Mode)
To configure a locking mode in Red Hat JBoss Data Grid's Remote Client-Server mode, use the
transaction element as follows:
<transaction locking="{OPTIMISTIC/PESSIMISTIC}" />14.3.7. Configure Locking Mode (Library Mode)
In Red Hat JBoss Data Grid's Library mode, the locking mode is set within the
transaction element as follows:
<transaction transactionManagerLookupClass="{TransactionManagerLookupClass}"
transactionMode="{TRANSACTIONAL,NON_TRANSACTIONAL}"
lockingMode="{OPTIMISTIC,PESSIMISTIC}"
useSynchronization="true">
</transaction>
Set the
lockingMode value to OPTIMISTIC or PESSIMISTIC to configure the locking mode used for the transactional cache.
