A5A, also known as Read Skew, happens when a transaction both observes and fails to observe the effects of another transaction. Specifically, Berenson et al defined A5A as a history in which transaction T_i reads x_i, T_j writes x_j and y_j then commits, and finally T_i reads y_j before committing or aborting.¹

In terms of dependencies, T_j rw-depends on T_i, since it overwrote the version of x which T_i read. However, T_j’s write of y is visible to T_i, which means that T_i wr-depends on T_j. Read Skew is therefore a special case of G-single.

For example, imagine a queen decides—moments before the ball—to change her heels from stilettos to a more practical pair of pumps. She ducks behind a curtain to change. Her mother glances over and observes her left shoe is a stiletto. The queen completes her change of shoes, and her mother sees a pump on her right foot. Her mother incorrectly concludes she is about to break an ankle.

Read Skew is allowed by Read Committed. It is proscribed by Snapshot Isolation and Repeatable Read—although the ANSI SQL definition of Repeatable Read actually allows it.

Literature

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

A5A Read Skew Suppose transaction T1 reads x, and then a second transaction T2 updates x and y to new values and commits. If now T1 reads y, it may see an inconsistent state, and therefore produce an inconsistent state as output. In terms of histories, we have the anomaly:

A5A: r1[x]…w2[x]…w2[y]…c2…r1[y]…(c1 or a1)

See Also

P2 can be viewed as a degenerate form of A5A, where the two objects x and y are the same.

Like P4, A5A is a special case of Adya’s G-single.