Isolation anomalies: Does a phantom read mean that, on reread, a transaction finds that previously read rows were modified or deleted by a committed transaction?

Introduction / Context:
Understanding isolation anomalies is critical for choosing the appropriate transaction isolation level. Common anomalies include dirty reads, non-repeatable reads, and phantoms. This question distinguishes between non-repeatable reads and phantom reads.

Given Data / Assumptions:

• A transaction reads some data, then later rereads.
• Between reads, another committed transaction changes the database.
• We must identify which anomaly matches “modifications or deletions of previously read rows.”

Concept / Approach:
Non-repeatable read occurs when a transaction rereads the same row and finds it changed or removed by another committed transaction. Phantom read occurs when a transaction rereads a set of rows defined by a predicate and finds new additional rows appear (or disappear) that match the predicate, even if previously read rows are unchanged. Phantoms are prevented by serializable isolation with predicate locking or by techniques like index-range locking.

Step-by-Step Solution:

Verification / Alternative check:
Compare definitions across textbooks: “phantom” refers to new tuples matching a predicate, while “non-repeatable” refers to changes to previously read tuples.

Why Other Options Are Wrong:

• Calling it a phantom confuses two distinct phenomena.
• References to serializable isolation or predicate locks do not make the given description a phantom.

Common Pitfalls:
Equating any second read difference with “phantom.” Always ask: did the set definition change (phantom) or did the same row’s values change (non-repeatable)?

Final Answer:
Incorrect: that describes a non-repeatable read