Monotonic atomic view is a consistency model which strengthens read committed by preventing transactions from observing some, but not all, of a previously committed transaction’s effects. It expresses the atomic constraint from ACID that all (or none) of a transaction’s effects should take place. Once a write from transaction T1 is observed by transaction T2, then all effects of T1 should be visible to T2. This is particularly helpful in enforcing foreign key constraints and ensuring indices and materialized views reflect their underlying objects.
Monotonic atomic view is a transactional model: operations (usually termed “transactions”) can involve several primitive sub-operations performed in order. It is also a multi-object property: operations can act on multiple objects in the system.
Monotonic atomic view can be totally available: in the presence of network partitions, every node can make progress. If you are willing to sacrifice total availability, both repeatable read and snapshot isolation offer stronger guarantees.
Note that monotonic atomic view does not impose any real-time constraints. If process A completes write w, then process B begins a read r, r is not necessarily guaranteed to observe w. For a transactional model that provides real-time constraints, consider strict serializability.
Moreover, monotonic atomic view does not require a per-process order between transactions. A process can observe a write, then fail to observe that same write in a subsequent transaction. In fact, a process can fail to observe its own prior writes, if those writes occurred in different transactions.
Like serializability, monotonic atomic view allows pathological orderings. For instance, a monotonic atomic view database can always return the empty state for any reads, by appearing to execute those reads at time 0. It can also discard write-only transactions by reordering them to execute at the very end of the history, after any reads. Operations like increments can also be discarded, assuming the result of the increment is never observed. Luckily, most implementations don’t seem to take advantage of these optimization opportunities.
Formally
Monotonic Atomic View is not commonly discussed in the literature, but was coined by Bailis, Davidson, Fekete, et al in Highly Available Transactions: Virtues and Limitations. They describe it as:
Under MAV, once some of the effects of a transaction Ti are observed by another transaction Tj, thereafter, all effects of Ti are observed by Tj. That is, if a transaction Tj reads a version of an object that transaction Ti wrote, then a later read by Tj cannot return a value whose later version is installed by Ti.
In terms of Adya’s formalization of transactional isolation levels, monotonic atomic view prohibits:
- G1b (Intermediate Reads): A transaction observes an object (perhaps via a predicate) modified by a transaction which was not that transaction’s final modification of that object. Intuitively, transactions have to finish before we can read them,
And since monotonic atomic view is strictly stronger than read committed, it also prohibits the ANSI phenomena…
- P0 (Dirty Write): w1(x) … w2(x)
- P1 (Dirty Read): w1(x) … r2(x)
but allows:
- P2 (Fuzzy Read): r1(x) … w2(x)
- P3 (Phantom): r1(P) … w2(y in P)
Here w denotes a write, r denotes a read, and subscripts indicate the transaction which executed that operation. The notation “…” indicates a series of micro-operations except for a commit or abort. P indicates a predicate.