Intuition The ONE core ideaA database lets many transactions run at the same time , but the moment two of them touch the same data, one can accidentally see the other's half-done or shifting work. Every anomaly in this topic is just a picture of one timeline peeking into another timeline's private draft — so before we name the glitches, we must first agree on what a transaction, a commit, and "the same time" even look like .
This page assumes nothing . If the parent note said "T 1 T 2 every word in that sentence means — as a picture, not a phrase.
A table is a grid of data: named columns across the top, and rows going down, one row per real-world thing (one account, one employee). A row is just one horizontal line of that grid.
Look at the figure below. The whole grid is the table accounts. The one highlighted horizontal strip is a row — the account with id = 1. Everything in this topic is about who is looking at that strip, and when .
Intuition Why we start hereEvery anomaly is described as "T 1 row has a shape.
A transaction is a bundle of reads and writes that the database treats as one all-or-nothing job . We name them T 1 T 2 T 3
The picture that matters: draw each transaction as its own horizontal timeline , left = earlier, right = later. Time flows the same way for both, so we stack the timelines and read them together.
Intuition Why the subscript, why two lines?We need at least two actors for any anomaly — one transaction can never corrupt only itself. The subscripts 1 2 whose action we mean. The two stacked timelines let us say precisely when relative to each other. That "when" is the whole game.
Read T1 ::: What does the "1" in T 1 Just a label — "transaction number one". It names which concurrent actor we are talking about; it carries no maths.
Intuition Why split WRITE into three?This split is exactly what separates the three anomalies later, so we earn it now:
UPDATE changes what's inside a row → causes non-repeatable reads.INSERT/DELETE change which rows exist → cause phantom reads.
Keep these two ideas visually apart in your head: value inside a strip vs how many strips there are .
Worked example The four verbs on one rowSELECT balance FROM accounts WHERE id=1; -- READ (peek, no change)
UPDATE accounts SET balance=0 WHERE id=1; -- WRITE (change inside the strip)
INSERT INTO accounts(id) VALUES(7); -- WRITE (new strip appears)
DELETE FROM accounts WHERE id=1; -- WRITE (strip vanishes)
Definition Commit / rollbackWhile a transaction runs, its writes are uncommitted — provisional, written in pencil , only visible (in principle) to itself. Two ways to end:
COMMIT — press the "make it permanent" button. The pencil becomes ink. Everyone can now trust these changes.ROLLBACK — press "undo everything". Every pencil mark this transaction made is erased as if it never happened.
The figure shows the pencil-vs-ink idea on a single balance value.
Intuition Why this is the heart of "dirty"The whole dirty read anomaly is: one transaction reads another's pencil marks, and then those marks get erased by a ROLLBACK. You based a decision on writing that officially never existed. Without the pencil/ink distinction, "dirty" is meaningless — so this is the most important symbol on the page.
What state is a write in before COMMIT? Uncommitted (provisional / "in pencil") — it may still vanish on ROLLBACK.
What does ROLLBACK do to every write of a transaction? Erases them all, as if the transaction never ran.
Two transactions are concurrent if their timelines overlap in time — one has not finished before the other starts. The database is free to slot their steps together in any order; that mixed sequence is called the interleaving .
only live here
If T 1 T 2 T 1 T 2 tax on overlap . The reason databases allow overlap anyway is speed : running jobs one-at-a-time wastes the machine. So the topic is the tension: overlap = fast but glitchy vs no overlap = safe but slow .
Definition Predicate / rangeA predicate is a condition a query uses to pick rows, written after WHERE, e.g. WHERE dept='Sales'. The set of rows matching it is the result set . A range is a predicate over an ordered value, like WHERE age > 30.
Picture the predicate as a net dropped over the grid: every row that satisfies the condition is caught in the net; the rest fall through.
Intuition Why we need the "net" pictureA phantom read is when you cast the net twice and catch a different number of fish — not because a fish changed colour (that's a value change = non-repeatable), but because someone dropped a new fish (INSERT) into the netted area. You cannot lock a row that "doesn't exist yet", which is why phantoms need locking the net's whole region (a range/predicate lock), a stronger idea covered in Locking — Shared and Exclusive Locks .
The row is caught by the net because... its column value satisfies the WHERE condition (the predicate). It's a member of the result set .
Dirty read uses Commit and Rollback
Non repeatable uses UPDATE
Phantom uses INSERT DELETE and Predicate
Isolation Levels fix them
Each arrow means "you must understand the left box to picture the right box". Notice the two writes-branches (UPDATE vs INSERT/DELETE) and the predicate net all feed the anomalies separately — that is why there are exactly three distinct glitches, not one.
Recall Foundation → which anomaly it unlocks
Row/table → lets us say "reads a row ".T 1 T 2 T 2 between T 1 UPDATE (write-inside) → non-repeatable read.INSERT/DELETE (write-count) → phantom read.Commit/rollback (pencil/ink) → dirty read.Predicate net → phantom read + the range locks in Isolation Levels .
For the medicine — how Isolation Levels , Locking — Shared and Exclusive Locks , MVCC — Multiversion Concurrency Control , Two-Phase Locking (2PL) and the safety guarantees of ACID Properties switch these glitches off — head back to the parent topic . (Beware: cranking isolation too high can cause Deadlocks — a different problem, not an anomaly.)
Test yourself — you are ready for the parent topic once every reveal matches your own words.
A "row" is one horizontal strip of a table's grid — one real-world record.
T 1 T 2 two concurrent transactions (all-or-nothing bundles of reads/writes); the subscript is just a name.
A READ (SELECT) does what to data only looks — changes nothing.
The three WRITE verbs are UPDATE (change inside a row), INSERT (add a new row), DELETE (remove a row).
"Uncommitted" means written provisionally ("in pencil"), visible only within its own transaction, and possibly about to be erased.
COMMIT vs ROLLBACKCOMMIT makes all writes permanent (pencil → ink); ROLLBACK erases all of the transaction's writes.
"Concurrent" means two transactions' timelines overlap — neither finished before the other started.
Why anomalies need overlap without overlap one transaction can't see the other's draft, so no glitch is possible.
A "predicate" / WHERE condition is a net that catches exactly the rows matching a condition — its catch is the result set.
Which write changes a row's value vs the set of rows UPDATE changes a value (→ non-repeatable); INSERT/DELETE change the set (→ phantom).
