When the Same Question Gets Different Answers
A Non-Repeatable Read (also called a Fuzzy Read) happens when a transaction reads the same row twice within a single transaction and gets different values each time, because another committed transaction modified that row in between.
The word "non-repeatable" captures the problem precisely: you cannot repeat a read and trust you will get the same answer.
How It Happens
Time Transaction A (Generate Invoice) Transaction B (Update Price)
---- ---------------------------------------- ----------------------------------
T1 BEGIN
T2 SELECT price FROM products WHERE id = 5
-- Returns: $10.00
T3 BEGIN
T4 UPDATE products SET price = 15.00 WHERE id = 5
T5 COMMIT
T6 SELECT price FROM products WHERE id = 5
-- Returns: $15.00 ← DIFFERENT!
T7 -- Invoice subtotal used $10, tax uses $15. Math is broken.
T8 COMMIT
Transaction A is now internally inconsistent. It calculated a subtotal using $10 and a tax using $15. The invoice is wrong, and no error was raised.
The Fix
The Repeatable Read isolation level (and its common implementation, Snapshot Isolation) prevents this. When Transaction A first reads the row at T2, the database takes a snapshot of that row's version. Every subsequent read of that row within the same transaction returns the snapshot version, regardless of what other transactions commit.
Key distinction: Non-Repeatable Read is about a specific row's values changing. This is different from Phantom Reads, which are about the set of rows matching a query changing.