Treating conflicts as a validation problem
Locking all relevant data in advance can introduce waiting and management overhead. An optimistic method lets transactions proceed and later checks whether their observations and updates still satisfy the required correctness condition.
Kung and Robinson’s 1981 paper relates the efficiency opportunity to workloads with relatively rare conflicts. Optimism does not remove consistency checking; it changes when checking and waiting occur. Frequent conflicts can cause completed work to be repeatedly discarded.
References: [1]
Reading, validating, and publishing changes
The original design separates a read phase, validation, and a possible write phase. Updates first affect local copies and become shared only after successful validation. Read and write sets help track interactions among concurrent transactions.
Checking only the finally written object need not cover every dependency. A decision can read several values and update only some of them. Validation must account for relevant relationships with other transactions rather than reducing every transaction’s requirement to one unchanged field.
References: [1]
Retries are part of the protocol
Failed validation requires rerunning the relevant transaction against suitable new state, not publishing results whose assumptions no longer hold. PostgreSQL’s isolation documentation likewise requires restarting the whole transaction after the relevant concurrency failure.
Optimistic approaches can reduce some lock waiting while retaining validation, metadata, and retry costs. Results depend on conflict rates, transaction length, and implementation. The label alone does not guarantee lock-free execution, freedom from starvation, or greater throughput for every workload.