Optimistic vs Pessimistic Locking: Detect-at-Commit vs Lock-Before-Access

Sun, 06 Sep 2026 09:49:36 +0900

Overview

Both are concurrency-control strategies for preventing lost updates when multiple transactions touch the same data, but they differ in when they deal with conflict. Optimistic locking assumes collisions are rare and only performs a version check at commit time, while pessimistic locking assumes collisions are likely and takes an exclusive lock before any read or write proceeds.

Comparison Diagram

Comparison Table

Aspect	Optimistic Locking	Pessimistic Locking
Access phase	No lock taken; any transaction can read or begin writing the row immediately	Lock acquired (e.g. SELECT FOR UPDATE) before the transaction reads or writes the row
Concurrent access	Other transactions freely read and write the same row in parallel	Other transactions attempting the same row must wait for the lock holder to finish
Conflict detection timing	Deferred until commit, via a version number, timestamp, or hash comparison	Not needed as a separate step; the lock physically prevents overlapping access
On conflict	Commit is rejected; the transaction is rolled back and typically retried	No conflict occurs; the waiting transaction simply blocks until the lock is released
Implementation mechanism	Application-level version column checked in the UPDATE’s WHERE clause	Database-level row or table locks managed by the lock manager
Throughput under low contention	High; no blocking overhead when collisions are rare	Lower; locking overhead is paid even when no real conflict would occur
Behavior under high contention	Retry storms and wasted work as many transactions repeatedly fail and re-run	Orderly queueing keeps correctness but serializes work and limits parallelism
Deadlock risk	None, since no locks are ever held	Possible when transactions acquire multiple locks in inconsistent order

Key Differences

Optimistic locking detects conflicts at commit time; pessimistic locking prevents them via upfront locking.
Optimistic locking never blocks other transactions, it only forces a retry on collision.
Pessimistic locking holds an exclusive lock for the transaction’s full duration, serializing access to the row.
Optimistic locking carries no deadlock risk because it never holds locks.
Pessimistic locking trades raw throughput for predictability when contention is heavy.

When to Use Each

Optimistic Locking

Serializable vs Weaker Isolation: Strict Ordering vs Controlled Anomalies

Sun, 06 Sep 2026 09:47:51 +0900

Overview

Serializable isolation guarantees that concurrent transactions produce a result equivalent to some serial order, eliminating every possible race condition. Weaker isolation levels like Read Committed or Snapshot trade that guarantee for higher throughput, deliberately allowing certain read/write anomalies that application code must tolerate or guard against.

Comparison Diagram

Comparison Table

Aspect	Serializable	Weaker Isolation
Isolation guarantee	Result equivalent to some serial execution of all transactions	Allows specific interleavings; guarantee varies by level (Read Committed, Repeatable Read, Snapshot)
Concurrency control	Full conflict serializability via strict two-phase locking, serializable snapshot isolation (SSI), or predicate locks	Row-level locks or MVCC snapshots that only block on narrower conflict sets (e.g. write-write)
Anomalies prevented	Dirty reads, non-repeatable reads, phantom reads, and write skew all eliminated	Only a subset prevented; phantoms and write skew commonly remain possible
Contention behavior	Higher rate of lock waits, deadlocks, or serialization-failure aborts under concurrent access	Readers rarely block writers (MVCC) or lower lock scope, so contention is reduced
Throughput impact	Lower throughput and higher latency as concurrency increases, especially with hot rows	Higher throughput and better scalability under contention
Application responsibility	Application can assume correctness; only needs to retry on serialization-failure errors	Application must reason about anomalies and add explicit checks (e.g. version columns, SELECT FOR UPDATE)
Conflict detection timing	Detected either at lock-acquisition time or at commit time (optimistic serializable schemes)	Detected only for the narrower conflicts the level covers, often just at commit for MVCC writes
Default in major databases	Rarely the default; must be explicitly requested (e.g. SET TRANSACTION ISOLATION LEVEL SERIALIZABLE)	Default in most systems out of the box (PostgreSQL/Oracle default to Read Committed, MySQL InnoDB to Repeatable Read)

Key Differences

Serializable enforces true serial equivalence; weaker levels only rule out a defined subset of anomalies.
Weaker isolation relies on MVCC snapshots or narrow locks, cutting contention compared to serializable’s broader locking or SSI conflict tracking.
Under Serializable, correctness bugs shift into retry loops on abort; under weaker levels, they shift into missed application-level checks.
Write skew is the classic anomaly Serializable closes that even Snapshot Isolation leaves open.
Choosing a level is a runtime trade-off between guaranteed correctness and throughput, not a one-time schema decision.

When to Use Each

Serializable

Concurrency-Control on IT Comparison

Optimistic vs Pessimistic Locking: Detect-at-Commit vs Lock-Before-Access

Overview

Comparison Diagram

Comparison Table

Key Differences

When to Use Each

Serializable vs Weaker Isolation: Strict Ordering vs Controlled Anomalies

Overview

Comparison Diagram

Comparison Table

Key Differences

When to Use Each