8. Transactions
8.6 THE ANOMALY TABLE — the single most useful table in the book
| Isolation level | Dirty reads | Read skew | Phantom reads | Lost updates | Write skew |
|---|---|---|---|---|---|
| Read uncommitted | ✗ Possible | ✗ Possible | ✗ Possible | ✗ Possible | ✗ Possible |
| Read committed | ✓ Prevented | ✗ Possible | ✗ Possible | ✗ Possible | ✗ Possible |
| Snapshot isolation | ✓ Prevented | ✓ Prevented | ✓ Prevented | ? Depends | ✗ Possible |
| Serializable | ✓ Prevented | ✓ Prevented | ✓ Prevented | ✓ Prevented | ✓ Prevented |
(Dirty writes are omitted because almost all transaction implementations prevent them.)
The six anomalies in one line each:
| Anomaly | Definition |
|---|---|
| Dirty read | One client reads another client's writes before they have been committed |
| Dirty write | One client overwrites data another client has written but not yet committed |
| Read skew (nonrepeatable read) | A client sees different parts of the database at different points in time |
| Phantom read | A transaction reads objects matching a search condition; another client makes a write that affects the results of that search. SI prevents straightforward phantoms; phantoms in the context of write skew require special treatment such as index-range locks |
| Lost update | Two clients concurrently perform a read-modify-write cycle; one overwrites the other's write without incorporating its changes |
| Write skew | A transaction reads something, decides based on what it saw, and writes the decision — but by the time the write is made, THE PREMISE OF THE DECISION IS NO LONGER TRUE. Only serializable isolation prevents this |