Dealing With Contention medium
How does Optimistic Locking handle concurrent updates without blocking?
- A It uses a `version` number or timestamp. When updating, it checks `WHERE version = read_version`. If the count is 0 (version changed by someone else), the update fails and the client must retry.
- B It hopes no one else updates the row.
- C It locks the table but allows reads.
- D It uses a distinct separate database.
Answer: A. It uses a `version` number or timestamp. When updating, it checks `WHERE version = read_version`. If the count is 0 (version changed by someone else), the update fails and the client must retry.
Preferred for high-concurrency systems where conflict is rare. It avoids holding database locks during user think time.
One system design question a day, with spaced repetition so the ones you miss come back.
Get the appRelated questions
- Why is 'Exponential Backoff' preferred over constant intervals for retries?
- What is the primary purpose of a Mutex (Mutual Exclusion) lock?
- Why does adding more threads sometimes *decrease* performance?
- In a Saga, if a Compensating Transaction (Undo) fails repeatedly due to contention, what is the last resort?
- In a database, what happens if Transaction A locks a row and Transaction B tries to modify the same row?
- A database restart causes thousands of application servers to instantly try to reconnect. This crashes the DB again. This is called: