Lock types

When you are using pessimistic and optimistic locking, shared (S), upgradeable (U) and exclusive (X) locks are used to maintain consistency. Understanding locking and its behavior is important when you have pessimistic locking enabled. With optimistic locking, the locks are not held. Different types of locks are compatible with others in various ways. Locks must be handled in the correct order to avoid deadlock scenarios.

Shared, upgradeable, and exclusive locks

When an application calls any method of the map programming interface, WebSphere® eXtreme Scale Client automatically attempts to acquire a lock for the map entry that is being accessed.

In Java applications, locks are also acquired when the applications uses the find methods on an index, or does a query.

LockMode is an enum with possible values where you can specify the keys that you want to lock:
  • SHARED, UPGRADABLE, and EXCLUSIVE
WebSphere eXtreme Scale Client uses the following lock modes that are based on the method the application calls in the map programming interface.
S lock
A shared lock mode for the key of a map entry. The duration that the S lock is held depends on the transaction isolation level used. An S lock mode allows concurrency between transactions that attempt to acquire an S or an upgradeable lock (U lock) mode for the same key, but blocks other transactions that attempt to get an exclusive lock (X lock) mode for the same key.
U lock
An upgradeable lock mode for the key of a map entry. The U lock is held until the transaction completes. A U lock mode allows concurrency between transactions that acquire an S lock mode for the same key, but blocks other transactions that attempt to acquire a U lock or X lock mode for the same key.
X lock
Exclusive lock mode for the key of a map entry. The X lock is held until the transaction completes. An X lock mode ensures that only one transaction is inserting, updating, or removing a map entry of a given key value. An X lock blocks all other transactions that attempt to acquire an S, U, or X lock mode for the same key.
An S lock mode is weaker than a U lock mode because it allows more transactions to run concurrently when they are accessing the same map entry. The U lock mode is slightly stronger than the S lock mode because it blocks other transactions that are requesting either a U or X lock mode. The S lock mode only blocks other transactions that are requesting an X lock mode. This small difference is important in preventing some deadlocks from occurring. The X lock mode is the strongest lock mode because it blocks all other transactions that are attempting to get an S, U, or X lock mode for the same map entry. The X lock mode ensures that only one transaction can insert, update, or remove a map entry and to prevent updates from being lost when more than one transaction is attempting to update the same map entry.
See the following table to understand the relationship between these lock mode values and the behavior of existing methods:
Table 1. LockMode values and existing method equivalents
Lock mode Method equivalent
SHARED get()
UPGRADABLE getForUpdate(), getAllForUpdate()
EXCLUSIVE getNextKey() and commit()

The following table is a lock mode compatibility matrix that summarizes the described lock modes, which you can use to determine which lock modes are compatible with each other. To read this matrix, the row in the matrix indicates a lock mode that is already granted. The column indicates the lock mode that is requested by another transaction. If Yes is displayed in the column, then the lock mode that is requested by the other transaction is granted because it is compatible with the lock mode that is already granted. No indicates that the lock mode is not compatible and the other transaction must wait for the first transaction to release the lock that it owns.

Table 2. Lock mode compatibility matrix
Lock Lock type S (shared) Lock type U (upgradeable) Lock type X (exclusive) Strength
S (shared) Yes Yes No weakest
U (upgradeable) Yes No No normal
X (exclusive) No No No strongest