Optimistic concurrency control (Kung & Robinson, 1981) detects a conflicting concurrent write after the fact and aborts/restarts the losing transaction, rather than preventing the race pre-emptively

concurrent-systemsdatabasesoptimistic-concurrency-controltransaction-processingconcurrency-control-history

H.T. Kung and John T. Robinson's 1981 ACM Transactions on Database Systems paper, "On Optimistic Methods for Concurrency Control," is the foundational source for what is colloquially called "optimistic locking" today, and for the broader concept now named optimistic concurrency control (OCC). The method runs transactions through a read phase, a validation phase, and a write phase: "all writes take place on local copies of the nodes to be modified" during the read phase, and the transaction commits globally only if a validation step at the end finds no conflicting concurrent transaction. The paper's own framing is explicit about the mechanism: "The methods used are 'optimistic' in the sense that they rely mainly on transaction backup as a control mechanism, 'hoping' that conflicts between transactions will not occur." When validation does find a conflict, the response is not a silent repair — "the transaction will be backed up and start over again as a new transaction." The paper frames locking and backup as the two control mechanisms practice relies on, with optimistic methods trading wait-and-block for detect-and-restart.

This distinguishes OCC from the TOCTOU-mitigation tradition (claim-cwe-367-362-prescribe-atomicity-locking-not-occ-or-event-sourcing), which prevents a check-then-act race pre-emptively via locking, and from the database "lost update" anomaly it is sometimes paired with (claim-lost-update-p4-distinct-from-toctou): OCC is lost update's own field's answer to that problem, not a TOCTOU fix. Structurally, OCC's "backed up and start over" step is a detect-after-the-fact, abort-and-retry discipline — closer to "notice the clobber, then correct it" than to a pre-emptive lock.