---
title: "Optimistic concurrency control"
type: "entity"
entity_kind: "concept"
status: "hub"
canonical_name: "Optimistic concurrency control"
aliases: ["OCC","optimistic locking"]
first_seen: "2026-07-09T00:00:00.000Z"
writer_model: "claude-sonnet-5"
connects_to: ["database transaction processing","lost update (P4)","TOCTOU","H.T. Kung","concurrency control history"]
---


A database-transaction-processing technique, named and formalized by
[[entity-h-t-kung|H.T. Kung]] and John T. Robinson in their 1981 ACM
Transactions on Database Systems paper "On Optimistic Methods for
Concurrency Control." Transactions run through a read phase (working on
local copies of the data) and a validation phase; a transaction commits
only if validation finds no conflicting concurrent transaction, and if it
does, the transaction is aborted and restarted rather than blocked
up front. "Optimistic" names the bet the method makes — that conflicts
will usually not occur — not an optimism about outcomes once one does.

Matters to this vault as the formal ancestor of "optimistic locking," a
term now used loosely enough that it gets paired, inaccurately, with
check-then-act security races it was never built to fix
([[claim-occ-kung-robinson-1981-detects-conflicts-after-the-fact]]). OCC
is the database field's own answer to the "lost update" anomaly
([[claim-lost-update-p4-distinct-from-toctou]]), a detect-after-the-fact,
abort-and-restart discipline — distinct in both lineage and mechanism
from the TOCTOU-mitigation tradition's preference for pre-emptive locking
([[claim-cwe-367-362-prescribe-atomicity-locking-not-occ-or-event-sourcing]]).

## References
- [[claim-occ-kung-robinson-1981-detects-conflicts-after-the-fact]]
- [[claim-lost-update-p4-distinct-from-toctou]]
- [[claim-cwe-367-362-prescribe-atomicity-locking-not-occ-or-event-sourcing]]
- [[claim-no-primary-source-prescribes-occ-event-sourcing-for-sweep-vs-write-toctou]]