A phenomenon is something a database does that someone, somewhere, thought was a bad idea. Whether a phenomenon is legal or not depends on the system’s consistency model. For example, G1a (Aborted Read) is legal under Read Uncommitted, but illegal under Read Committed.
Adya
These phenomena, based on Adya’s 1999 thesis, characterize consistency models (mostly) in terms of dependencies between transactions.
| Phenomenon | A.K.A. |
|---|---|
| G0 | Write Cycle |
| G1a | Aborted Read |
| G1b | Intermediate Read |
| G1c | Cyclic Information Flow |
| G-single | Single Anti-dependency Cycle |
| G-nonadjacent | Non-adjacent Anti-dependency Cycle |
| G2-item | Item Anti-dependency Cycle |
| G2 | Anti-dependency Cycle |
SQL
From the ANSI SQL standard1 and subsequent work by Berenson et al, these phenomena characterize SQL isolation levels. They are defined in terms of event order, rather than dataflow, which makes them less useful for distributed systems.
| Phenomenon | A.K.A. |
|---|---|
| P0 | Dirty Write |
| P1 (A1) | Dirty Read |
| P2 (A2) | Non-Repeatable Read, Fuzzy Read |
| P3 (A3) | Phantom |
Temporal
These phenomena involve the temporal order of events, either on a single process or across multiple processes.
| Phenomenon | A.K.A. |
|---|---|
| Stale Read | |
| Real-Time |
Other
| Phenomenon | A.K.A. |
|---|---|
| Lost Write | Write Loss |