When should I use pessimistic locking in NCache?

Use pessimistic locking when your application faces high data contention where concurrent updates are likely to conflict. It is ideal for critical operations, such as financial transactions (e.g., bank account withdrawals), where you must ensure that only one client can access and modify an item at any given time to prevent race conditions.

How does optimistic locking handle conflicts in NCache?

Optimistic locking manages conflicts through Cache Item Versioning. Every item is assigned a numeric version that increments with each update. When a client attempts to save changes, NCache compares the client's version with the server's version. If they don't match (indicating another client updated the data), the operation fails, and an exception is thrown, prompting the application to fetch the latest data and retry.

Optimistic vs Pessimistic Locking in Cache

NCache provides an efficient distributed locking mechanism, including both optimistic and pessimistic locking, to ensure data synchronization and integrity in environments where cache data is accessed and updated by multiple concurrent clients. By enforcing cache-level concurrency control, NCache helps maintain atomicity, consistency, and isolation for read and write operations across the entire cache cluster.

Locking becomes necessary when shared cache resources are accessed concurrently, as parallel operations can otherwise lead to race conditions and inconsistent data. NCache addresses this requirement by allowing applications to either acquire exclusive locks (pessimistic locking) or rely on version-based (optimistic locking) conflict detection, ensuring consistency across the entire cache cluster for every update to the same data. Additionally, NCache provides you with an API to lock specific cache data so that only a single thread or application can update or read it.

When to Use Distributed Locking

Problem Statement

Consider a scenario where there is a unique bank account used by two account holders. The account holds a balance of $5000. User 1 wants to withdraw $2000 from the account and User 2 wants to deposit $1000 to the account. Given these conditions, the account balance after performing these operations must be $4000 (5000-2000 = 3000 and 3000+1000 = 4000).

Now, suppose both users perform their operations at the same time and the application does not handle the concurrent updates correctly. The following sequence may occur:

User 1 checks the account balance and it shows $5000. He withdraws $2000 and the total balance becomes $3000.
User 2 checks the account balance and it shows $5000. He deposits $1000 and the total balance becomes $6000.

The following diagram depicts the scenario visually.

Illustration showing how optimistic and pessimistic locking prevent inconsistent updates in a shared bank account scenario

Solution

To resolve this shared resource problem, NCache provides two locking approaches that you can apply depending on your concurrency requirements.

The first approach exclusively locks the bank account while one user performs an operation on it. While this exclusive lock is held, other users following the same lock-aware API workflow cannot update the account. After the user completes the withdrawal and releases the lock, another user can safely deposit money. All clients must use the lock-aware overloads for this coordination to work; overloads that ignore locks can still access or update the item.
The second approach allows the bank account to remain accessible to multiple users at the same time. Each user can read and operate on the account, but the account version is updated after every successful update. When a user attempts to update the balance, the version is checked to ensure no other update has occurred in the meantime. If the version has changed, the operation fails and the user must re-fetch the latest balance before retrying. This approach allows higher concurrency while still maintaining data consistency.

NCache provides both locking mechanisms, known as Pessimistic and Optimistic Locking. They are further explained in subsequent sections.

Comparing Optimistic vs Pessimistic Locking Strategies

There are two types of locking available in NCache:

Pessimistic Locking (Exclusive Locking)
Pessimistic locking uses a LockHandle to make a cache item inaccessible to other clients while the lock is held.
Optimistic Locking (Cache Item Versioning)
Optimistic Locking is a mechanism where item versioning is used to manage concurrency. Using this mechanism, an item is open for use by another user, but after every successful update to the item, its version is incremented.

Optimistic vs Pessimistic Locking in Cache

When to Use Distributed Locking

Problem Statement

Solution

Comparing Optimistic vs Pessimistic Locking Strategies

See Also

Contact Us