Exclusive lock semantics: Does an exclusive (X) lock allow others to read but block changes, or does it block both readers and writers?

Introduction / Context:
Lock modes control what concurrent operations can proceed. Understanding how exclusive locks interact with shared locks is essential for reasoning about isolation and blocking behavior.

Given Data / Assumptions:

• An exclusive (X) lock is held by one transaction on a resource (e.g., row/table).
• Other transactions may attempt shared (S) or exclusive (X) locks on the same resource.
• We consider classical two-phase locking semantics.

Concept / Approach:
A shared (S) lock allows concurrent readers but not writers. An exclusive (X) lock allows a single writer and conflicts with both S and X requests from others—blocking both reads and writes. Some MVCC systems let others read old versions without acquiring S locks, but under a locking-based model, an X lock prevents other transactions from reading the locked item because they cannot acquire a compatible S lock.

Step-by-Step Solution:

Verification / Alternative check:
Check DBMS documentation for lock compatibility charts; exclusive locks conflict with both shared and exclusive requests.

Why Other Options Are Wrong:

• Claiming “X allows reads” misstates compatibility; readers need S which conflicts with X.
• Snapshot/MVCC exceptions present different mechanisms (versioned reads), not the semantics of the X lock itself.

Common Pitfalls:
Confusing MVCC’s non-blocking reads with lock compatibility. MVCC reads avoid S locks but that is due to versioning, not because X permits reads.

Final Answer:
Incorrect: X lock blocks both reads and writes by others