optimistic concurrency control pattern
Don't take a lock when you start writing. Read the row + its version, do your work, on commit verify the row's version hasn't changed since you read it. If it has, retry. Great when conflicts are rare; degrades when they're common (livelock from contention).
Don't take a lock when you start writing. Read the row + its version, do your work, on commit verify the row's version hasn't changed since you read it. If it has, retry. Great when conflicts are rare; degrades when they're common (livelock from contention).
symptoms
- need concurrency without lock contention
- conflict rate is low
causes
- pessimistic locks serialize too aggressively
- read-heavy workload
fixes
- version column on the row
- UPDATE ... WHERE version = ?
- retry the transaction on conflict
you might say
- OCC
- CAS on version
- optimistic lock