Optimistic concurrency control lets concurrent mutations proceed without locks, then asks the commit phase to reconcile their results. Each calculation proceeds as if it were alone; the commit either accepts, merges, or aborts the mutation. This keeps reads and writes responsive, but moves complexity into conflict handling. section 5.1 section 5.6
A mutation follows this division of responsibility:
- Calculate the next state in isolation without changing shared state. section 5.1
- Commit by comparing the current, previous, and proposed states. section 5.5
- Use a fast-forward when the current state still equals the previous state; otherwise attempt a three-way merge. section 5.5 section 5.6
- Abort when concurrent changes overlap in a way the reconciliation algorithm cannot safely merge, then ask the user to retry. section 5.5 section 5.6
Two mutations, one shared state
Mutation A calculates from version P while mutation B commits first, producing version C. When A reaches commit, it compares P, C, and its proposed version N. If their changes use separate paths, it merges N into C; if they conflict, it throws a conflict and leaves C intact. section 5.5
Table 5.1 The two phases of a mutation with optimistic concurrency control (view table figure)
The phase table makes the central trade-off visible: calculation is stateless and mutation-specific, while commit is stateful and shared. section 5.1
