Optimistic Concurrency Control

In the LangGraph scenario, the fencing token is usually implemented as a lease_epoch or version column in the lease table, atomically incremented on each ownership transfer, and the checkpoint write statement takes the form UPDATE checkpoints SET ... WHERE thread_id = ? AND lease_epoch = ?; if the affected row count is zero, ownership has been lost and the worker should immediately abort the current task.

Optimistic concurrency control assumes conflicts are uncommon and detects conflicts only at write time, in contrast to pessimistic locking, which locks before writing.

The Anthropic team introduced optimistic concurrency control into the memory system: before each memory write, a hash is taken, and another hash is taken at write time; if the two differ, the write is rejected and the agent is required to re-read and re-draft.

Optimistic concurrency control checks only at commit time whether there is a conflict with other transactions, and if there is a conflict, it rolls back and retries; throughput is higher in low-conflict scenarios, but when writing concurrently to the same partition or the same table, the number of retries rises significantly and can even lead to a higher transaction failure rate.

Lakehouse solutions mostly adopt optimistic concurrency control together with atomic commits at the metadata layer.

In high-contention financial hotspot scenarios, optimistic concurrency control causes most transactions to fail the version check, triggering a retry storm.

High-reliability ledgers use optimistic concurrency control (OCC) together with immutable append constraints, or use pessimistic row-level locking (SELECT ... FOR UPDATE) on account pointer records.

The "last-write trap" described in the article is the Lost Update problem in distributed systems; one standard solution is optimistic concurrency control, which operates on the same principle as a database CAS operation.

Before committing to storage, the target record, permitted change types, and current record version number should be validated; if they are inconsistent with the proposal, the current record should be retained and the conflict routed to a human for handling.

Iceberg and Delta Lake use optimistic concurrency control mechanisms, where write operations commit transactions by atomically updating the pointer to the current metadata file.

When two catalogs each permit writes, they may independently advance their respective maintained pointers, causing one commit to overwrite the other and resulting in data loss or state inconsistency.