A5B, also known as Write Skew, happens when two committed transactions write different objects, and each fails to observe the other’s write. If there were a constraint between the two objects—for example, that their sum should not exceed a threshold—that constraint could be violated. This phenomenon comes from Berenson et al’s Snapshot Isolation paper.

Formally, transaction T_i reads x_i, and transaction T_j reads x_i. Then T_i writes y_j, and T_j writes x_j. Both transactions commit. In terms of dependencies, each transaction rw-depends on the other, since it overwrote the version the other transaction read. Write Skew is therefore a special case of G2-item.

For example, imagine two electricians working on the same panel concurrently. Each performs a transaction to add a new circuit. Each reads all the current circuits to ensure there is sufficient capacity to add their intended circuit. They both find that there are 160 out of 200 amps available, and each installs a new 30 amp circuit on two different slots. When their transactions complete, the panel uses 220 amps; a safety constraint has been violated.

A5B is allowed by Snapshot Isolation. It is proscribed by Repeatable Read and Serializability.

Literature

Berenson et al’s Snapshot Isolation paper defined A5B thus:

A5B Write Skew Suppose T1 reads x and y, which are consistent with C(), and then a T2 reads x and y, writes x, and commits. Then T1 writes y. If there were a constraint between x and y, it might be violated. In terms of histories:

A5B: r1[x]…r2[y]…w1[y]…w2[x]…(c1 and c2 occur)

Note that Berenson’s prose does not match the history: in the history, T1 reads only x, and T2 reads only y, rather than both reading both objects. The history captures the minimal read-write dependency edges between the two transactions.

See Also

A5B is a special case of G2-item.