Question bank — Concurrency anomalies — dirty read, non-repeatable read, phantom read

False — the danger is realised on rollback, but the dirty read itself is defined the moment $T_1$ reads $T_2$'s uncommitted value. Even if $T_2$ later commits, the read was still "dirty" because at read time the data was not stable.

True — that is exactly its nature. Both reads see committed data; the problem is the committed value changed between them, so $T_1$ sees two truths about one row.

True — every anomaly requires a second transaction ($T_2$) to modify data during $T_1$'s lifetime. With no concurrency there is no "other" work to leak in.

False — it only refuses to read uncommitted data. It happily reads committed data, including values that a concurrent transaction commits and re-commits repeatedly.

False — it freezes the rows you read, killing non-repeatable reads, but new rows matching a range can still appear (phantoms). Only Serializable gives the "ran alone" guarantee.

False — no existing row's value need change. A brand-new row (INSERT) or a vanished row (DELETE) alters which rows match your condition; the surviving rows can be untouched.

False on the "always" — Serializable removes all three anomalies but throttles concurrency, raising contention, deadlocks, and aborts. Pick the lowest level that forbids the anomalies your logic actually cares about.

True — reads never mutate data, so a lone read by $T_2$ cannot make $T_1$'s data shift. All three anomalies trace back to a write (uncommitted for dirty; committed UPDATE for non-repeatable; committed INSERT/DELETE for phantom).

False — the value could have been changed to $X$ and back to $X$ by committed writes between the reads, or the equality could be luck. "Same value observed" is weaker than "guaranteed stable". Stability is a property the isolation level provides, not something you infer from one lucky match.

Wrong label — an existing row's value changed (UPDATE), so this is a non-repeatable read. Phantoms are about the set of matching rows changing via INSERT/DELETE.

Wrong label — the membership of the result set changed, not any existing row's value, so this is a phantom read. Non-repeatable is about a row you already read moving under you.

Wrong guarantee — Read Committed only makes each individual read see committed data. Cross-read stability of one row requires Repeatable Read.

Wrong tool — row locks protect rows that already exist. A phantom is a new row entering the range, which no existing-row lock covers. You need range/predicate (next-key) locks or serialization.

Wrong — before it rolls back, its uncommitted write can be read by $T_1$ (dirty read). The rollback is precisely what makes that read a lie; the trace is the wrong decision $T_1$ already made.

Wrong — the SQL standard allows phantoms at Repeatable Read. Some engines (e.g. InnoDB) go beyond the standard and block them via next-key locks, but that is engine-specific, not the standard.

Wrong — it means the observable result is equivalent to some serial order. Transactions may still overlap physically; the engine enforces serializability via locking or conflict detection, not by forcing single-file execution.

Because the two questions are independent: "when" splits uncommitted (dirty) from committed (the other two), and "what" splits value-of-a-row (non-repeatable) from membership-of-a-set (phantom). Two binary axes give exactly the distinct cases we need.

A dirty read is defined by reading uncommitted data — a single read of the wrong kind of value is enough. The other two are defined by inconsistency between two reads, so they need a first read to be contradicted by a second.

Preventing non-repeatable reads means locking/snapshotting the rows you have already read so they can't change. A phantom is a row you haven't read yet because it didn't exist when you looked — there's nothing to lock until you also lock the condition it would match.

More isolation means holding locks longer or over wider ranges (or aborting more conflicting transactions). That reduces how many transactions can proceed simultaneously, increasing waiting, deadlock risk, and abort/retry cost — throughput drops.

Because the correct level is the lowest one that forbids the anomalies your business logic can't tolerate. Over-isolating pays a performance tax for safety you don't need; under-isolating admits a bug. The anomaly set is the actual requirement.

MVCC — Multiversion Concurrency Control gives $T_1$ a consistent point-in-time snapshot, so its re-reads see the same version it first saw. $T_2$ writes a new version without waiting, so readers and writers don't block each other — the re-read is stable by construction, not by locking. See also Isolation Levels.

This straddles the boundary: the specific row you read disappearing is often treated as a non-repeatable read (the row you held changed — to non-existent), but because it also changes range membership many texts call it a phantom. The clean rule: value-change of a still-present row = non-repeatable; change in which rows match a predicate = phantom. A DELETE of a matched row is a membership change → phantom under the strict "set" definition.

The dirty read still occurs (you read uncommitted data), but the harmful consequence doesn't materialise this time because the value was later confirmed. It's a latent bug: correct by luck, wrong whenever a rollback eventually does occur.

No — a phantom requires the matching set to change. An insert outside the predicate leaves $T_1$'s result identical, so no anomaly is observed for that query.

For $T_1$'s two observations the result set is unchanged (empty both times), so $T_1$ observes no phantom. Anomalies are defined by what a transaction observes, not by unrelated churn it never sees.

No — all three anomalies are triggered by a write from the other transaction. Two pure readers cannot disturb each other, regardless of isolation level.

It is immune to the three standard anomalies, so its result equals some serial order. But "serial order" may place $T_1$ logically before recent commits, so data can still feel "old" — that's correct, not an anomaly, because a consistent serial position is exactly the guarantee. This is why Serializable can force aborts under Two-Phase Locking (2PL) and raises Deadlocks risk.

Not a concurrency anomaly — with no concurrent writer, the change came from $T_1$'s own write between the reads, which is intended behaviour. Anomalies require another transaction's interference.