Isolation & Anomalies

Dirty read

Transaction A updates your delivery status to "Out for Delivery" but hasn't committed yet (maybe it's still mid-way through also charging your card). Transaction B — the tracking page you're refreshing — reads "Out for Delivery" and shows it to you. Then Transaction A's payment fails and it rolls back. Your delivery status reverts to "Preparing" — but you already saw, and maybe acted on, information that never actually existed. That's a dirty read: reading another transaction's uncommitted changes.

Non-repeatable read

Within one report-generation transaction, you read your wallet balance twice — once at the start, once at the end, to double-check a calculation. Between those two reads, a completely different, already-committed transaction (someone paying you back) changes your balance. Your two reads within the same transaction disagree with each other. That's a non-repeatable read.

Phantom read

You run "count all my orders over ₹500" twice within one transaction, expecting the same number both times since you're not writing anything yourself. Between the two runs, another transaction (a new order you just placed on a different device) commits a new qualifying row. Your second count is different from your first, even though you never touched anything — a whole new row "phantom" appeared. That's a phantom read.

Anomaly	What changes between two reads
Dirty read	You read data that was never actually committed at all.
Non-repeatable read	The same row, read twice, has different values.
Phantom read	The same query, run twice, returns a different set of rows.

Isolation Level	Dirty Read	Non-Repeatable Read	Phantom Read
Read Uncommitted	Possible	Possible	Possible
Read Committed	Prevented	Possible	Possible
Repeatable Read	Prevented	Prevented	Possible*
Serializable	Prevented	Prevented	Prevented

BEGIN TRANSACTION ISOLATION LEVEL REPEATABLE READ;

SELECT balance FROM wallets WHERE user_id = 42; -- first read
-- ... other work happens here, possibly a slow report calculation ...
SELECT balance FROM wallets WHERE user_id = 42; -- guaranteed to match the first read, under REPEATABLE READ

COMMIT;

@Transactional(isolation = Isolation.SERIALIZABLE)
public void generateFinancialReport(Long accountId) {
    // every read inside here is guaranteed a fully consistent, non-changing view,
    // as if no other transaction ran concurrently at all
}

BEGIN TRANSACTION ISOLATION LEVEL REPEATABLE READ;

SELECT balance FROM wallets WHERE user_id = 42; -- first read
-- ... other work happens here, possibly a slow report calculation ...
SELECT balance FROM wallets WHERE user_id = 42; -- guaranteed to match the first read, under REPEATABLE READ

COMMIT;

Use case	Recommended level	Why
Typical CRUD web app	Read Committed	Good balance — dirty reads are the most dangerous anomaly and are already prevented; the others are rare and often tolerable.
Financial report, multi-step calculation	Repeatable Read or Serializable	Correctness across multiple reads within one transaction matters more than raw throughput.
High-throughput, high-contention counter updates	Read Committed + row-level locking (Chapter 07)	Serializable's overhead under heavy contention can tank throughput; targeted locking is often more practical.