Optimistic Concurrency Control
Optimistic concurrency control lets people work at the same time without locking first. Before saving, it checks the version and rejects a change based on old data.
Another example
Two clinicians open care plan revision 17. The first saves revision 18 with `If-Match: "r17"`. The second gets 412, compares the fields, merges with care, and retries with `"r18"`; no update is quietly lost.
Main parts
- 01Read version token
- 02Conditional write
- 03Conflict response and merge
Use it when
Use version checks when conflicts are rare, edits matter, and the product can help people compare and recover.
Do not use it when
After a version check fails, do not automatically retry edits whose order changes the result. Avoid this method when conflicts are constant and costly.
Name used in code
ETag + If-Match / version column + conditional update Before you ship
Check contracts and invariants, authorization, and input limits. Test retries, one-time effects, timeouts, and partial failures. Verify data integrity, compatibility, monitoring, recovery, and rollback.
Outcome: Design or review Optimistic Concurrency Control for this system while keeping data correct, secure, and easy to operate. User context: Two clinicians open care plan revision 17. The first saves revision 18 with `If-Match: "r17"`. The second gets 412, compares the fields, merges with care, and retries with `"r18"`; no update is quietly lost. Technical concept or control: Optimistic Concurrency Control. Why it fits: Use version checks when conflicts are rare, edits matter, and the product can help people compare and recover. Do not use it when: After a version check fails, do not automatically retry edits whose order changes the result. Avoid this method when conflicts are constant and costly. Engineering requirements: Define inputs, outputs, contracts, and rules that must always hold. Set authorization and input checks. Define failures, timeouts, retries, one-time effects, data moves, and compatibility limits. Operations: Add useful signals and logs that hide sensitive data. Set capacity limits and write an operator guide. Test recovery and rollback. Acceptance criteria: Contract and failure-path tests pass. Data and authorization rules still hold during retries and partial failures. Check performance limits, monitoring, recovery, and rollback. Evidence and limits (evidence boundary): No single official standard controls the whole term. Its meaning may change across teams, platforms, or frameworks. Unknowns to confirm: Where the code runs, data stores, traffic shape, consistency needs, and the security boundary. Also confirm the compatibility period, service goals, and rollback limits.
Check this request
Review the current use of Optimistic Concurrency Control. Definition: Optimistic concurrency control lets people work at the same time without locking first. Before saving, it checks the version and rejects a change based on old data. Release checks: Check contracts and invariants, authorization, and input limits. Test retries, one-time effects, timeouts, and partial failures. Verify data integrity, compatibility, monitoring, recovery, and rollback. Before changing code, report the evidence you found, gaps, severity, and the smallest safe fix.