Transaction anomalies and isolation What is it called when a transaction reads data that was modified by another transaction but not yet committed (i.e., uncommitted changes)?

Introduction / Context:
Transaction isolation defines which phenomena can occur when multiple transactions execute concurrently. Recognizing anomalies helps you choose the right isolation level and locking strategy for correctness and performance.

Given Data / Assumptions:

• A transaction reads a row that another transaction has changed but not committed.
• We want the standard name for this anomaly in database theory and practice.

Concept / Approach:

A read of uncommitted data is classically termed a dirty read. If the writing transaction later rolls back, the reader will have observed a value that never becomes durable, violating consistency expectations and leading to incorrect decisions by the reading transaction.

Step-by-Step Solution:

Verification / Alternative check:

Standard texts and DBMS documentation list dirty reads as allowed at READ UNCOMMITTED and disallowed at READ COMMITTED and above, confirming the term and conditions.

Why Other Options Are Wrong:

• Nonrepeatable read: re-reading the same row yields a different committed value later.
• Phantom read: re-executing a range query returns new rows that were inserted by others.
• Consistent read: a term used by some engines (e.g., snapshot reads) to mean a stable view, not an anomaly.
• Lost update: concurrent updates overwrite each other; different anomaly.

Common Pitfalls:

• Equating dirty reads with nonrepeatable reads; the former involves uncommitted data.
• Assuming all engines even allow dirty reads; many default to READ COMMITTED.

Final Answer:

Dirty read.