Optimistic vs Pessimistic Locking: Choosing the Right Concurrency Control Strategy

In production environments, the choice between optimistic and pessimistic locking depends on the level of concurrency: low concurrency can safely use pessimistic locking, while high concurrency benefits from optimistic locking to avoid performance bottlenecks.

Pessimistic locking assumes a high probability of conflict, so it locks the target object before any modification and holds the lock until the transaction is committed, which can significantly limit access for other users.

Optimistic locking assumes conflicts are rare; it does not lock during read or edit, only checking for conflicts at commit time. This reduces lock duration and improves throughput, but may require a retry when a conflict is detected.

The article illustrates common concurrency problems such as lost updates and inconsistent reads using simple examples of two developers (Xiao Zhang and Xiao Li) editing files or packages simultaneously, showing how each lock type handles these scenarios.

Two main techniques for handling concurrent modifications are isolation (allowing only one activity to access data at a time) and immutability (making shared data read‑only). Both aim to reduce conflict chances.

When data is mutable and cannot be isolated, optimistic and pessimistic concurrency controls are the primary strategies. Optimistic locking detects conflicts at commit, while pessimistic locking prevents them by exclusive access.

Choosing the appropriate lock hinges on access frequency and the severity of potential conflicts: if conflicts are rare or their impact is low, optimistic locking is preferred for better concurrency; otherwise, pessimistic locking is safer.

Practical implementation suggestions include using transaction rollback in C# or SQL for optimistic locking, disabling submit buttons on ASPX pages, using a global flag in jQuery to prevent duplicate submissions, and employing modal dialogs to enforce single‑user editing for pessimistic locking.