Transaction timeline (isolation)
Medium+14 XPTwo transactions, one row. Watch a lock force one to WAIT so their writes don't collide — isolation, made visible on a timeline.
No visualization loaded.
Watch
—
Press Run to begin.
When two transactions change the SAME row at the same time, one of them can quietly erase the other's change — the 'lost update.' Databases prevent it with isolation, often using a lock. Press Run and watch two transactions share one bank balance: one grabs a lock, the other is forced to WAIT its turn, and because it waits, no update is lost. Rows are the two transactions; columns are time.
▸What would go wrong WITHOUT the lock?
Both transactions would read the same starting balance (100). T1 adds 50 and writes 150; T2 added 30 to the SAME stale 100 and writes 130 — overwriting T1's change. T1's +50 just vanished. That silent 'lost update' is exactly what isolation exists to stop.
▸What is the lock actually doing?
It's the only key to that row. While T1 holds it, T2 isn't allowed to touch the row at all — it must WAIT. When T1 commits, it drops the key; only then can T2 grab it and proceed. The lock turns 'both at once' into 'one fully finishes, then the next' for that row.
▸Why does T2 read 150 instead of 100 the second time?
Because it waited until T1 COMMITTED. By the time T2 finally locks the row, T1's change is permanent, so T2 reads the up-to-date 150 — not the stale 100 it would have grabbed if it had charged in early. Waiting is what guarantees it sees correct data.
▸Isn't making T2 wait slow?
A little — that's the cost of safety, and it's the whole tradeoff behind isolation levels. Stricter isolation means more waiting but no anomalies; looser means less waiting but risks like lost updates. Here we chose correctness: a tiny pause beats silently losing someone's money.