Introduction / Context:
Isolation levels trade off concurrency and correctness. READ COMMITTED is a widely used default that prevents reading uncommitted data yet still allows some anomalies that stronger levels prevent.
Given Data / Assumptions:
- Goal: identify the level that blocks dirty reads only.
- We recognize standard levels: READ UNCOMMITTED, READ COMMITTED, REPEATABLE READ, SERIALIZABLE, and vendor-specific SNAPSHOT.
Concept / Approach:
READ COMMITTED guarantees that all data seen has been committed. However, between two reads, other transactions may commit updates or insert new qualifying rows, allowing nonrepeatable reads and phantom reads. Stronger levels add protections but at higher contention cost.
Step-by-Step Solution:
1) READ UNCOMMITTED allows dirty reads → not the answer.2) READ COMMITTED forbids dirty reads but allows nonrepeatable and phantom reads → this matches the description.3) REPEATABLE READ prevents nonrepeatable reads on previously read rows, though phantoms may persist depending on the engine.4) SERIALIZABLE prevents both nonrepeatable reads and phantoms by ensuring an execution equivalent to some serial order.5) SNAPSHOT (where available) prevents many anomalies with versioning but is not the canonical answer to this description.
Verification / Alternative check:
ANSI/ISO isolation descriptions and major DBMS documentation align: READ COMMITTED disallows dirty reads while permitting the others under concurrency.
Why Other Options Are Wrong:
- Read uncommitted: still allows dirty reads.
- Repeatable read: typically prevents nonrepeatable reads.
- Serializable: prevents both nonrepeatable and phantom reads.
- Snapshot isolation: vendor-specific semantics; not the textbook match.
Common Pitfalls:
- Assuming READ COMMITTED prevents all anomalies; it does not.
- Conflating engine-specific REPEATABLE READ with serializable semantics.
Final Answer:
Read committed.
Discussion & Comments