Try an update, then check whether its input changed

Locks make conflicting transactions wait before proceeding. Another strategy lets work proceed tentatively, then checks whether its observations are still valid. This is optimistic concurrency control. “Optimistic” describes when the check happens, not permission to ignore conflicts.

Use a single stock record containing count 1 and version number 7. A version number changes whenever this record is successfully updated. For this narrow example, a transaction’s decision depends only on this one record.

Validate and publish as one protected decision

Both buyers read count 1 at version 7 and privately plan count 0. Neither has yet published a purchase.

A checks and commits
Under one protected validation-and-publication step, A confirms version 7, installs count 0, and advances the version to 8.
B reaches validation
B expected version 7 but finds 8. Its earlier decision is no longer valid, so this attempt aborts.
B retries from fresh data
It reads count 0 and reports that no stock remains.

Only the winning attempt publishes a purchase. A failed validation does not create a second order.

The check and publication must be coordinated. If both buyers check version 7 before either installs version 8, separate successful checks would not prevent two purchases. A compare-and-swap primitive can combine a narrow comparison and update; a multi-record transaction needs a more complete commit protocol.

Real transactions may depend on multiple rows and on predicates such as “no order with this ID exists.” Validating only the rows written is not generally enough to prove serializable behavior. The validation rules must match the promised isolation level.

Compare useful work, not just active workers

If most transactions touch unrelated records, validation may succeed almost every time. If thousands compete for one record, many can perform work that is later discarded. Retrying them increases the load without increasing successful purchases at the same rate.

A single ordered worker is another option for a narrow workload. It can process conflicting operations one at a time and avoid some repeated speculation, but limits parallel work and can delay small requests behind long ones. Locking, optimistic execution, and ordered execution place waiting or wasted work in different places.

Remove the shared record

A updates product 27 while B updates product 46. Each decision depends only on its own product. Must one abort because both transactions run at the same time?

Check dependencies rather than overlap alone

No. Under this narrow model, neither changes the other’s input, so both can validate successfully. If they also depend on a shared limit across both products, that extra dependency must be represented and checked. The set of records written does not necessarily describe the whole business rule.

We now have two ways to coordinate transaction decisions. Both still require safe access to the engine’s internal memory, which is the next topic.

CMU’s concurrency project explores optimistic multiversion execution. Our single-record version check illustrates one ingredient, not that complete protocol.

Extended reference

The extended chapter preserves the original technical coverage, additional examples, and citations. The explanation above supplies the concepts needed for this page; the reference develops the specialist cases.

Find a section from the original chapter