Questions: Non-Repeatable Read Anomaly

Question 1

Transaction T1 reads an account balance and sees $1000. T2 then updates the balance to $200 and commits. T1 re-reads the same row and sees $200. Which isolation level permits this behavior?

• A. SERIALIZABLE
• B. REPEATABLE READ
• C. READ COMMITTED
• D. This behavior is impossible under any standard isolation level

Answer: (C)

Under READ COMMITTED, each statement sees the latest committed snapshot at the moment that statement begins. Since T2 committed before T1's second SELECT, T1 sees the new value — a non-repeatable read. Both REPEATABLE READ and SERIALIZABLE prevent this by ensuring T1's snapshot is held for the entire transaction, not just per statement.

Question 2

Which of the following scenarios describes a non-repeatable read (and not another isolation anomaly)?

• A. T1 reads uncommitted changes written by T2 that T2 later rolls back
• B. T1 reads a row, T2 updates and commits it, T1 re-reads the same row and sees a different value
• C. T1 issues a range query, T2 inserts a new matching row, T1 re-issues the query and sees an extra row
• D. T1 and T2 both read and then update the same row, and T1's update overwrites T2's

Answer: (B)

A non-repeatable read involves reading the same specific existing row twice and getting different values because another transaction modified it in between. Option A is a dirty read (uncommitted data). Option C is a phantom read (new rows in a range). Option D is a lost update. All involve concurrency anomalies but are distinct phenomena.

Question 3

The non-repeatable read anomaly can occur under READ COMMITTED isolation.

• T. True
• F. False

Answer: True

READ COMMITTED guarantees consistency per-statement, not per-transaction. Each new SELECT within a transaction sees the latest committed data at the time that statement runs. If another transaction commits a change between your first and second SELECT on the same row, your second SELECT sees the new value. This is the definition of a non-repeatable read.

Question 4

A non-repeatable read and a phantom read are the same anomaly described differently.

• T. True
• F. False

Answer: False

They are distinct. A non-repeatable read involves a specific existing row returning a different VALUE on re-read (due to an UPDATE or DELETE by another transaction). A phantom read involves a range query returning DIFFERENT ROWS on re-execution (due to INSERTs by another transaction). One is about changed values in existing rows; the other is about new rows appearing in a result set.

Question 5

Why does REPEATABLE READ prevent non-repeatable reads, and what is the cost of this stronger guarantee?

Model answer: REPEATABLE READ gives each transaction a consistent snapshot — either at transaction start or first statement — that doesn't change even if other transactions commit updates. T1 always sees the same row values throughout its life. The cost is reduced concurrency: lock-based systems hold shared read locks for the entire transaction duration (increasing blocking and deadlock risk); MVCC systems must retain old row versions for longer, increasing storage overhead.

The tradeoff is always consistency vs. concurrency. REPEATABLE READ trades some throughput for predictable within-transaction behavior: you can safely read the same data multiple times and reason about it. Systems that need high concurrency often accept the weaker READ COMMITTED guarantee and handle the resulting inconsistencies in application logic.