In database concurrency control, which type of lock prevents other transactions from modifying an item but still allows them to read it?

Introduction / Context:This question tests your understanding of lock modes used by a Database Management System (DBMS) to coordinate concurrent access. Specifically, it asks which lock permits reads but prevents writes, a core idea behind isolation and concurrency.

Given Data / Assumptions:

• Multiple transactions may access the same data item concurrently.
• We need a lock that blocks updates but allows reads.
• Standard lock nomenclature: shared (S) vs. exclusive (X).

Concept / Approach:A shared (S) lock is designed for read-only access. Many transactions can hold S locks concurrently on the same item. An exclusive (X) lock is required for updates and is incompatible with other S or X locks, preventing both reads and writes by others while held.

Step-by-Step Solution:

Verification / Alternative check:Compatibility matrix: S with S = compatible (reads proceed). S with X = incompatible (updates blocked). This matches the requirement.

Why Other Options Are Wrong:

• Implicit lock: refers to who sets the lock (DBMS automatically), not the lock's permission model.
• Explicit lock: set by the application; again, not a lock mode.
• Exclusive lock: blocks both reads (by others) and writes; too restrictive.

Common Pitfalls:Confusing “implicit/explicit” (how a lock is obtained) with “shared/exclusive” (what a lock allows). The question is about behavior, not acquisition method.

Final Answer:Shared lock