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 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 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 equivalentsLock 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 matrixLock |
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 |