Optimistic vs. pessimistic locking What is the primary advantage of optimistic locking in high-concurrency applications?

Difficulty: Medium

Correct Answer: The lock is obtained only when the transaction is ready to write or commit changes.

Explanation:


Introduction / Context:
Optimistic locking is a concurrency control strategy that assumes conflicts are rare. Instead of locking rows up-front, transactions proceed and validate at commit time, improving throughput when contention is low.


Given Data / Assumptions:

  • Many reads and relatively fewer conflicting writes.
  • Application can retry on conflict (e.g., version column mismatch).
  • We compare optimistic vs. pessimistic approaches.


Concept / Approach:

Optimistic locking avoids holding locks during long business logic phases. It typically uses a version/timestamp check at update time. If another transaction has changed the row, the update fails and must be retried. The benefit is reduced blocking and better scalability under low-conflict patterns.


Step-by-Step Solution:

1) Read the data and carry a version value (e.g., row_version = 12).2) Perform processing without locking the row.3) On update, check that the current row_version is still 12.4) If unchanged, update and increment the version; if changed, detect conflict and retry.5) Locks (or write latches) are acquired only at the final write phase, not throughout.


Verification / Alternative check:

Empirical performance studies show optimistic techniques excel when conflicts are rare because they minimize blocking and deadlocks, though they may degrade with frequent conflicts due to retries.


Why Other Options Are Wrong:

  • Obtaining the lock before processing (pessimistic) increases blocking time.
  • “No lock ever required” is false; writes ultimately require coordination.
  • High-conflict workloads favor pessimistic locking to avoid repeated retries.
  • Optimistic locking does not guarantee serializability by itself; it enforces write integrity via version checks.


Common Pitfalls:

  • Using optimistic locking where conflicts are frequent, causing thrashing.
  • Forgetting to include a version column check, leading to lost updates.


Final Answer:

The lock is obtained only when the transaction is ready to write or commit changes.

More Questions from Managing Multiuser Databases

Discussion & Comments

No comments yet. Be the first to comment!
Join Discussion