Practice the vocabulary of detecting a write conflict at commit time instead of locking upfront.
0 / 5 completed
1 / 5
At standup, a dev mentions letting a transaction proceed without locking anything, then checking at commit time whether another transaction modified the same data in the meantime, rejecting one if there's a conflict. What is this approach called?
Optimistic concurrency control, or OCC, lets a transaction proceed without locking anything, checking only at commit time whether another transaction modified the same data, and rejecting one if there's a genuine conflict. Pessimistic locking instead blocks every other transaction from touching the same data upfront, which can hurt throughput when conflicts are actually rare. This optimistic approach is what lets a system avoid unnecessary blocking under a workload where a real conflict is uncommon.
2 / 5
During a design review, the team wants every update to check and increment a row's version number, rejecting the update if the version doesn't match what was originally read. Which capability supports this?
A version-based compare-and-swap check on update verifies a row's version number still matches what was originally read, rejecting the update if it doesn't, which indicates another transaction modified that row in the meantime. Updating every row unconditionally with no version check risks silently overwriting a change made by another transaction. This compare-and-swap check is the concrete mechanism that makes optimistic concurrency control actually detect a real conflict.
3 / 5
In a code review, a dev notices the application includes retry logic that re-reads and re-applies a rejected update, since OCC causes a genuine conflict to be rejected rather than silently blocked and resolved automatically. What does this represent?
Retry logic handling a rejected update re-reads and re-applies the change after a detected conflict, since OCC rejects a genuine conflict outright rather than silently blocking and resolving it automatically the way a lock would. Rejecting a conflicting update with no retry logic discards the user's intended change without ever actually applying it. This retry handling is a necessary companion to optimistic concurrency control, since a rejection on its own isn't a complete solution.
4 / 5
An incident report shows two concurrent updates to the same record both succeeded and one silently overwrote the other's change, because the version check that OCC depends on hadn't actually been implemented on that particular write path. What practice would prevent this?
Implementing the version-based compare-and-swap check on every write path ensures a genuine conflict between two concurrent updates is actually detected and one of them rejected. Allowing every update to succeed unconditionally, with no version check anywhere, is exactly what let one update silently overwrite the other in this incident. This check has to be implemented consistently everywhere OCC is relied upon, or its protection is only partial.
5 / 5
During a PR review, a teammate asks why the team uses optimistic concurrency control instead of pessimistic locking for updating a frequently read but rarely conflicting record. What is the reasoning?
OCC avoids the lock contention pessimistic locking would introduce under a workload where a genuine conflict is rare, since most transactions never actually collide with another one touching the same record. The cost is needing an explicit retry the rare time a real conflict does occur, since OCC rejects rather than blocks. The tradeoff shifts depending on how frequently a real conflict actually happens in the specific workload.