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.
When you are using pessimistic
locking, you can use the lock methods to lock keys without returning any data values. With the lock
methods, you can lock the key in the data grid or lock the key and determine whether the value
exists in the data grid.
LockMode is an enum
with possible values where you can specify the keys that you want to lock:
SHARED, UPGRADABLE, and EXCLUSIVE
Shared, Upgradable, 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 modes and the behavior of equivalent methods:
Table 1. LockMode values and
ObjectMap method equivalents
Lock mode (Java / .NET) |
Java method equivalent |
.NET method equivalent |
SHARED / Shared |
get and getAll methods on the
ObjectMap interface, index methods, and queries |
Get(),
GetAndLock(Key,LockMode.Shared), GetAndLockAll(KeyList,
LockMode.Shared),GetAll methods |
UPGRADABLE /Upgradable |
getForUpdate(), getAllForUpdate()
|
GetAndLock(Key, LockMode.Updgradable),
GetAndLockAll(KeyList, LockMode.Upgradable) |
EXCLUSIVE / Exclusive |
getNextKey(), commit(), put, putAll,
remove, removeAll, insert, update, and touch methods, global invalidate and
global invalidateAll methods. (No locks are acquired for the local
invalidate and invalidateAll methods because none of the
BackingMap entries are invalidated by local invalidate method calls.)![Deprecated feature](icons/spn_depfeat.gif) Note: The upsert and upsertAll methods
replace the ObjectMap
put and putAll methods. Use the upsert
method to tell the BackingMap and loader that an entry in the data grid must place the key and value
into the grid. The BackingMap and loader either inserts or an updates to place the value into the
data grid and loader. If you run the upsert API within your applications, then
the loader gets an UPSERT LogElement type, which allows loaders to do database merge or
upsert calls instead of using insert or update.
|
Commit(), Add, AddAll, Put, PutAll, Remove, RemoveAll,
Replace, ReplaceAll, Touch, TouchAll, Invalidate, InvalidateAll Note: The Put and
PutAll methods are equivalent to the Java upsert and
upsertAll methods.
|
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 |