Concurrency anomalies — dirty read, non-repeatable read, phantom read: Visual walkthrough

We build everything from the ground up. No word is used before it is drawn.

Step 1 — The only two things a transaction can do to shared data

WHAT. Before anomalies, we need the alphabet. A transaction is just a to-do list of steps a database runs as one unit (see ACID Properties for why "one unit" matters). On any single piece of data — call it a row — a transaction does exactly one of two things:

Read it (look at the value, change nothing), written $R (x)$ = "read row $x$ ".
Write it (change the value), written $W (x)$ = "write row $x$ ".

And at the end it either commits (writes become permanent, symbol $C$ ) or rolls back (writes are thrown away, symbol $A$ for "abort").

WHY these symbols. We need a compact language so two transactions can be drawn side by side on the same clock. That side-by-side clock is where every anomaly lives — an anomaly is never about one transaction alone, it's about interleaving.

PICTURE. Time flows left → right. Two lanes: $T_{1}$ on top, $T_{2}$ below. Each tick is one step.

Figure — Concurrency anomalies — dirty read, non-repeatable read, phantom read

Step 2 — The single root cause (draw it once, reuse three times)

WHAT. Every one of the three anomalies is the same sentence:

$T_{1}$ made a decision using data that was not stable — either not committed, or changed by $T_{2}$ between two of $T_{1}$ 's looks.

WHY this matters. If we can draw "unstable data" as a picture, we don't memorize three separate bugs — we recognize one shape and ask two yes/no questions to name which flavor it is.

PICTURE. A value line for row $x$ over time. Green = committed & stable. Red = provisional or shifting. An anomaly is whenever $T_{1}$ 's read arrow lands on red.

Now we walk each branch of that tree as its own timeline.

Step 3 — Branch A: Dirty Read (the read arrow lands on RED)

WHAT. $T_{2}$ writes row $x$ but has not committed. $T_{1}$ reads $x$ now, while it's still red. Then $T_{2}$ aborts ( $A$ ) — the value is erased.

WHY this step exists. This is the "Q1 = No" branch: $T_{1}$ trusted a value the database never promised to keep. The write was pencil; the abort was the eraser.

PICTURE. Watch the red write at $t_{2}$ , the $T_{1}$ read arrow at $t_{3}$ pulling that red value up into $T_{1}$ , then the abort at $t_{4}$ deleting it — leaving $T_{1}$ holding a ghost.

T2 writes, uncommitted W_{2} (x = 0) T1 reads the red value R_{1} (x) \to 0 T2 aborts: x was never 0 A_{2}

$W_{2} (x = 0)$ — $T_{2}$ sets balance to $0$ , but no $C$ yet, so it's provisional (red).
$R_{1} (x) \to 0$ — $T_{1}$ 's read arrow lands on red; $T_{1}$ now believes $0$ .
$A_{2}$ — the rollback. The value $T_{1}$ read never officially existed.

Step 4 — Branch B: Non-Repeatable Read (green, but the value MOVED)

WHAT. $T_{1}$ reads $x$ and gets a committed (green) value. $T_{2}$ then does an UPDATE on that same existing row and commits. $T_{1}$ reads $x$ again — different green value.

WHY it's a different bug from dirty. Q1 is now Yes (both reads see committed data — nothing red). The problem is that the green value itself slid between $T_{1}$ 's two looks. $T_{1}$ is internally inconsistent: it saw two truths about one row.

PICTURE. Two read arrows from $T_{1}$ hitting the same row line at different heights, with $T_{2}$ 's committed update in the gap between them.

first look, committed R_{1} (x) \to 100 T2 updates existing row & commits W_{2} (x = 150) C_{2} second look, different! R_{1} (x) \to 150

$R_{1} (x) \to 100$ — first look, a legal committed value.
$W_{2} (x = 150) C_{2}$ — $T_{2}$ changes the same row and commits (green, not red).
$R_{1} (x) \to 150$ — same query, same row, new answer. Not repeatable.

Step 5 — Branch C: Phantom Read (the SET of rows moved)

WHAT. $T_{1}$ asks a range question — WHERE dept='Sales' — and counts $10$ rows. $T_{2}$ INSERTs a new matching row and commits. $T_{1}$ asks the same question and now counts $11$ .

WHY it's a third bug. Q1 = Yes again (all committed, all green). But Q2's answer flips: no existing row changed value. A brand-new row walked into the range. Locking the $10$ rows you read does nothing — the intruder wasn't among them.

PICTURE. A shaded "range box" (the dept='Sales' predicate). First scan: $10$ dots inside. $T_{2}$ drops an $11$ th dot into the box. Second scan: $11$ dots — a phantom appeared.

scan the box R_{1} (range) \to 10 new row enters the box INSERT_{2} C_{2} phantom row appears R_{1} (range) \to 11

$R_{1} (range)$ — a predicate read, not a single-row read. It scans whichever rows match.
$INSERT_{2} C_{2}$ — a row that didn't exist is created inside the predicate and committed.
$R_{1} (range) \to 11$ — the membership of the result set changed.

Step 6 — The degenerate & boundary cases (never leave a gap)

WHAT. We must check the corners, or the reader hits an unshown scenario.

PICTURE. Four mini-timelines, one per corner.

$T_{2}$ commits instead of aborting in Step 3. Then $T_{1}$ 's read of $0$ was... still a dirty read at the moment it happened — the anomaly is defined by reading uncommitted data, not by the eventual outcome. Dirtiness is about when, not what happens later.
$T_{1}$ reads a row exactly once. Non-repeatable read is impossible — you need two reads to compare. One look can't disagree with itself.
Empty range in Step 5 (WHERE dept='Sales' matches $0$ rows first). A single insert still makes $0 \to 1$ : phantom reads include the case of rows appearing from nothing and (by symmetry, via DELETE) rows vanishing to nothing.
$T_{2}$ touches a different row than $T_{1}$ reads. No anomaly at all — the read arrow never lands on the changed data. Anomalies require overlap on the same row or the same predicate.

The one-picture summary

All three anomalies are one timeline template with two switches flipped:

Recall Feynman retelling of the whole walkthrough

Draw two runners on the same track (that's the schedule). Runner $T_{1}$ keeps glancing at a scoreboard while running.

If $T_{1}$ reads a score the other runner scribbled in pencil and then rubbed out — dirty read.
If $T_{1}$ reads the score, looks away, looks back, and the same box now shows a different (but officially-written-in-pen) number — non-repeatable read.
If $T_{1}$ counts "5 scoreboards", looks back, and a brand-new sixth scoreboard has been bolted to the wall — phantom read. Same picture, one question each: was it in pen? (no → dirty), and did an old box change or a new box appear? (change → non-repeatable, appear → phantom). The database can freeze less or more of the wall — freezing more kills more glitches but slows everyone down. Choose the least freezing that stops the glitch your logic cares about.