Phenomenon G1b (Intermediate Read) occurs when a committed transaction observes an intermediate state produced by another transaction. Specifically, transaction T_i writes at least two versions of object x: some version x_intermediate, and its last write to x, x_final. Committed transaction T_j then reads x_intermediate. G1b is legal under Read Uncommitted, but proscribed by Read Committed.

For example, imagine T_i sets x to 1, then 2. Transaction T_j reads x = 1 and commits. Intermediate state has leaked out of T_i.¹

Note that G1b only constrains the reads of committed transactions; uncommitted transactions may read whatever they like.

If writes are arbitrary transformations of values (rather than blind writes), this definition of G1b is insufficient. Imagine an aborted transaction T_i writes an intermediate version x_i, and a committed transaction T_j writes x_j = f(x_i). Finally, a committed transaction T_k reads x_j. Clearly, intermediate state has leaked from T_i into T_k, but no G1b has occurred. We could resolve this by considering every write an implicit read: T_i and T_j would therefore constitute G1b. Jepsen opts to call this phenomenon Intermediate Update.

Formally

G1b is defined in Adya’s thesis, section 3.2.2:

G1b: Intermediate Reads. A history H exhibits phenomenon G1b if it contains a committed transaction T_j that has read a version of object x (maybe via a predicate) written by transaction T_i that was not T_i’s final modification of x.

See Also

Intermediate Read is a (less obvious) aspect of the ANSI SQL anomaly P1 (Dirty Read). However, P1 has two interpretations: one allows non-Serializable histories, and the other rules out Serializable histories. Adya’s G1 captures the spirit of P1 in three general, precise phenomena: G1a (Aborted Read), G1b (Intermediate Read), and G1c (Cyclic Information Flow). Ruling out all three ensures Read Committed.