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.

When is optimistic locking better in NCache?

Optimistic locking is superior for read-intensive applications with low data contention. Since it uses item versioning instead of exclusive handles, it allows higher concurrency by not blocking other threads. It is best used when conflicts are rare, as it only checks for version mismatches at the time of the update.

What happens if I forget to unlock an item in pessimistic locking?

If a pessimistic lock is not explicitly released using the Unlock API, the item remains inaccessible to other clients. To prevent infinite deadlocks, NCache supports lock timeouts. If a timeout is specified during acquisition, NCache automatically releases the lock after the interval expires. For crashed applications, NCache also provides a forceful Unlock API to clear abandoned locks.

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.

Can NCache locking guarantee ACID properties in a cluster?

Yes. NCache's distributed locking ensures atomicity, consistency, and isolation for shared resources across the entire cache cluster. By using these mechanisms, you make your critical data sets fault-tolerant and synchronized even when accessed by multiple parallel clients.

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 parallel clients. By enforcing cache-level concurrency control, NCache guarantees atomicity, consistency, and isolation for read and update 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 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. Considering the given conditions, the account balance after performing these operations must be $4000 (5000-2000 = 3000 and 3000+1000 = 4000).

Now let's consider that both users want to perform this operation on the account at the same time and since there is no proper handling for the scenario, the following things happen:

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 is locking the bank account for any further operation when one user is already performing an operation on it. While this exclusive lock is held, other users cannot read or update the same account. After the user completes the withdrawal and releases the lock, another user can safely deposit the balance. This approach prevents concurrent access and guarantees strict consistency.
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 operation. 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 mechanisms of Locking, known as Pessimistic and Optimistic Locking. They are further explained in successive chapters.

Comparing Optimistic vs Pessimistic Locking Strategies

There are two types of Locking available with NCache:

Pessimistic Locking (Exclusive Locking)
Pessimistic Locking is a mechanism where an item is exclusively locked using a LockHandle due to which the item remains inaccessible for other users while locked.
Optimistic Locking (Cache Item versioning)
Optimistic Locking is a mechanism where item versioning is used to lock an item. Using this mechanism, an item is open for use by another user, but on every operation performed on an item, the item version updates itself.

Optimistic vs Pessimistic Locking in Cache

When to Use Distributed Locking

Problem Statement

Solution

Comparing Optimistic vs Pessimistic Locking Strategies

See Also

Contact Us