From a Config Update API to Locking Strategies: Optimistic vs Pessimistic Locks Explained

1 Business Implementation Discussion

Last week the team discussed an API for modifying configuration data that also has a management UI. When a client reads the config, updates it, and submits the change, another concurrent modification could overwrite the first update, causing inconsistency.

To prevent this, the API was enhanced with an optimistic lock: the current version number is read together with the data, and the update request includes that version. The database checks the version; if it matches, the update succeeds, otherwise it fails.

The simple logic can still cause failures if not handled carefully, prompting a review of optimistic and pessimistic lock concepts.

2 Basic Definitions

Pessimistic lock : assumes conflicts are frequent; acquires an exclusive or shared lock before accessing data, causing other transactions to block until the lock is released.

Optimistic lock : assumes conflicts are rare; does not hold locks during read, but validates at commit time (e.g., version check). On conflict, the operation may retry, roll back, or raise an error.

3 Core Comparison Dimensions

Conflict assumption : Pessimistic – frequent conflicts, pre‑emptive protection; Optimistic – infrequent conflicts, post‑check.

Lock mechanism : Pessimistic – holds exclusive/shared lock during read/write, blocking others; Optimistic – no continuous lock, only version verification.

Underlying idea : Pessimistic – exclusive access, serial execution; Optimistic – concurrent access with conflict detection.

Typical DB implementation : Pessimistic – SELECT ... FOR UPDATE (row‑level lock); Optimistic – version column, CAS, timestamp.

Typical Java implementation : Pessimistic – synchronized, ReentrantLock; Optimistic – Atomic classes, LongAdder, DB version control.

Performance characteristics : Pessimistic – stable under high contention, but adds lock overhead under low load and can cause many context switches; Optimistic – no blocking overhead, but high conflict rates lead to many retries and CPU usage.

Suitable scenarios : Pessimistic – write‑heavy, frequent conflicts, cannot tolerate retry failures; Optimistic – read‑heavy, low conflict probability, tolerant of occasional retry.

4 Implementation Details

4.1 Pessimistic Lock

A transaction begins, issues a SELECT ... FOR UPDATE to lock the row, performs updates, and commits. The lock is held for the transaction duration.

Note: Database‑level pessimistic locks rely on a transaction and the storage engine (e.g., InnoDB). Outside a transaction, FOR UPDATE has no effect.

-- start transaction
BEGIN;
SELECT * FROM goods WHERE id = 10 FOR UPDATE;
-- modify data
UPDATE goods SET stock = stock - 1 WHERE id = 10;
COMMIT;

Risk: long‑running transactions can cause lock waiting and deadlocks.

4.2 Optimistic Lock (Version‑Number Scheme)

Add a version column to the table.

Read the current version together with the data.

When updating, include WHERE version = :oldVersion; on success increment the version.

UPDATE goods
SET stock = stock - 1,
    version = version + 1
WHERE id = 10
  AND version = #{oldVersion};

If the affected row count is 1, the update succeeded.

If the count is 0, another transaction modified the row; the business layer may retry or abort.

CAS (Compare‑And‑Swap) is an in‑memory optimistic lock used by Java’s AtomicInteger, which relies on CPU primitives to compare expected and current values and retry on failure.

5 Common Misconceptions

Optimistic lock does not eliminate concurrency problems; it only detects conflicts at update time.

Optimistic lock cannot replace pessimistic lock when the business requires guaranteed successful updates without retries (e.g., strong consistency for financial deductions).

CAS suffers from the ABA problem; using version numbers or timestamps (e.g., AtomicStampedReference) mitigates it.

6 Selection Guidance

Choose pessimistic lock for write‑intensive workloads, high contention, or when failures are unacceptable and retry logic is undesirable.

Choose optimistic lock for read‑dominant workloads, low conflict probability, environments where blocking is costly, or distributed systems where implementing a distributed pessimistic lock is complex.

7 Conclusion

Pessimistic locking trades throughput for safety by blocking other transactions, while optimistic locking enables higher concurrency by detecting conflicts after the fact. Neither approach is universally superior; the choice depends on read/write ratios, conflict frequency, and tolerance for update failures.