Isolation Levels and the Anomalies They Allow
Full isolation is expensive, so databases offer weaker levels, each defined by which anomalies it permits: dirty reads, non-repeatable reads, phantoms. Choosing a level is choosing which wrong answers the application can tolerate.
What a learner can do afterwards
- Produce an interleaving that shows a non-repeatable read
- Match each named anomaly to the lowest level that forbids it
- Choose an isolation level for a stated workload and justify it
1 · Read
You already know a transaction groups reads and writes. Full isolation is expensive, so databases offer weaker levels. Each level is defined by which wrong answers it permits, and choosing one means choosing which wrong answers your app can tolerate.
Picture a non-repeatable read. Your transaction reads a balance of 100. Another transaction changes it to 80 and commits. Your transaction reads again and gets 80. The same query twice gave two answers inside one transaction.
The three named anomalies stack up. A dirty read sees data that was never committed. A non-repeatable read sees committed changes between its own reads. A phantom sees brand-new rows appear in a repeated range query. Each stronger level forbids one more: read committed forbids dirty reads, repeatable read forbids non-repeatable reads, and serializable forbids phantoms.
Match the level to the workload and say why. A bank balance needs serializable because money must never blur. A rough analytics count can run looser, since a slightly stale total harms nobody.
Each isolation level permits certain anomalies, so pick the weakest level whose wrong answers your app can tolerate.
2 · Watch
Take it off screen
Where it sits
8 questions wait behind this lesson, each with its answer explained. Every answer feeds the sky: stars light as they are learned, and dim when it is time to come back.