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

Difficulty: Easy

Correct Answer: Shared lock

Explanation:


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:

Identify the requirement: allow read, disallow change.Map lock modes: S allows read; X allows change and blocks others.Therefore the correct mode is the shared (S) lock.


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

Discussion & Comments

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