Anomaly 1: Dirty Read

Reading Data That Might Disappear

A Dirty Read occurs when a transaction reads data that has been written by another transaction but not yet committed. The word "dirty" means the data is potentially invalid — the writing transaction might still roll back, erasing those changes entirely.

Think of it like reading a colleague's draft email before they decide whether to send or delete it. You might act on information that was never meant to be final.

How It Happens

Consider a bank transfer:

Time  Transaction A (Transfer $100 to Bob)    Transaction B (Read Bob's Balance)
----  ---------------------------------------- ----------------------------------
T1    BEGIN
T2    UPDATE accounts SET balance = balance + 100 WHERE user = 'Bob'
T3                                             BEGIN
T4                                             SELECT balance FROM accounts WHERE user = 'Bob'
                                               -- Sees $100 extra (DIRTY READ)
T5    ROLLBACK  -- Transfer cancelled!
T6                                             -- Bob's balance is now wrong in T2's memory
T7                                             COMMIT  -- Acts on phantom data

Transaction B read a balance that technically never existed. If Transaction B then sent Bob a "Your balance is $X" email or made a lending decision, it acted on a lie.

The Fix

The Read Committed isolation level prevents dirty reads. It ensures a transaction only ever sees data that has been fully committed. This is the default in PostgreSQL and Oracle. Under Read Committed, Transaction B at T4 would see Bob's original balance, not the in-flight update.