Dealing With Contention medium
When should you use Pessimistic Locking (`SELECT ... FOR UPDATE`)?
- A When you want to be faster.
- B When you are reading data only.
- C When contention is high and the cost of retrying a failed transaction is very expensive (e.g., long calculation). It prevents conflict by serializing access upfront.
- D When using NoSQL.
Answer: C. When contention is high and the cost of retrying a failed transaction is very expensive (e.g., long calculation). It prevents conflict by serializing access upfront.
If collisions are frequent, Optimistic Locking leads to a retry loops. Pessimistic Locking slows everyone down but guarantees progress order.
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: