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 automatically attempts to acquire a lock for the map entry that is being accessed.

[Java programming language only] 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.) 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