Optimistic Concurrency Control

Concept. Optimistic concurrency control (OCC) runs transactions with no locks. Each moves through three phases: a read phase that computes on a private copy, a validate phase at commit that checks whether any row it read was written by a transaction that committed since it started, and a write phase that applies the changes if validation passed. A failed validation aborts and retries. OCC bets conflicts are rare, so most transactions sail straight through.

Intuition. Mickey and Minnie both edit the same playlist at once. Neither waits. Both do their work on private copies; at commit Mickey validates first and commits. Minnie then finds the row she read has changed, throws her work away, and redoes it on the new value. No one ever blocked, but Minnie paid by running twice.

Locking is pessimistic: it assumes a clash and blocks to prevent one. MVCC keeps versions so readers never wait. OCC takes the third path: assume the best, run free, and pay only when a clash happens.

Two transactions run with no locks. Each has a read phase on a private copy, a validate phase at commit, and a write phase. T1 validates clean and commits (green). T2 ran over the same window but at validate finds a row it read was written by T1, fails (red), aborts, and reruns its read phase. The validate check: did any row I read get written by a transaction that committed since I started?

Figure 1. Both transactions run lock-free and check only at commit. T1 validates clean and commits (green); T2 finds a row it read was written by T1, so it fails validation (red), aborts, and reruns. Under two-phase locking T2 would have waited; here the cost of never waiting is redoing the work on a clash.

When it wins, when it loses

OCC's whole bet is that the validate check usually passes. When contention is low (transactions rarely touch the same rows), almost nothing aborts and OCC runs at lock-free speed with none of locking's blocking or bookkeeping. When contention is high, the same rows clash again and again; transactions abort and retry, burning work, and a hot row can starve. That is exactly where pessimistic locking, which waits instead of redoing, pulls ahead.

So the three strategies split cleanly by where the cost lands: 2PL pays by waiting, OCC pays by redoing, and MVCC sidesteps the reader-writer wait entirely by keeping versions.

Next

Connecting It All Together → Three strategies, one correctness standard. The last page assembles them into a single transaction system.