Tests for an anomaly in parallel snapshot isolation (but which is prohibited in normal snapshot isolation). In long-fork, concurrent write transactions are observed in conflicting order. For example:

T1: (write x 1) T2: (write y 1) T3: (read x nil) (read y 1) T4: (read x 1) (read y nil)

T3 implies T2 < T1, but T4 implies T1 < T2. We aim to observe these conflicts.

To generalize to multiple updates…

Let a write transaction be a transaction of the form (write k v), executing a single write to a single register. Assume no two write transactions have the same key and value.

Let a read transaction be a transaction of the form (read k1 v1) (read k2 v2) …, reading multiple distinct registers.

Let R be a set of reads, and W be a set of writes. Let the total set of transactions T = R U W; e.g. there are only reads and writes. Let the initial state be empty.

Serializability implies that there should exist an order < over T, such that every read observes the state of the system as given by the prefix of all write transactions up to some point t_i.

Since each value is written exactly once, a sequence of states with the same value for a key k must be contiguous in this order. That is, it would be illegal to read:

[(r x 0)] [(r x 1)] [(r x 0)]

… because although we can infer (w x 0) happened before t1, and (w x 1) happened between t2, there is no second (w x 0) that can satisfy t3. Visually, imagine bars which connect identical values from reads, keeping them together:

key   r1    r2    r3    r4

x     0     1 --- 1 --- 1

y     0     1 --- 1     0

z     0 --- 0     2     1

A long fork anomaly manifests when we cannot construct an order where these bars connect identical values into contiguous blocks.

Note that more than one value may change between reads: we may not observe every change.

Note that the values for a given key are not monotonic; we must treat them as unordered, opaque values because the serialization order of writes is (in general) arbitrary. It would be easier if we knew the write order up front. The classic example of long fork uses inserts because we know the states go from nil to some-value, but in our case, it could be 0 -> 1, or 1 -> 0.

To build a graph like this, we need an incremental process. We know the initial state was nil nil nil …, so we can start there. Let our sequence be:

    r0

x   nil
y   nil
z   nil

We know that values can only change away from nil. This implies that those reads with the most nils must come adjacent to r0. In general, if there exists a read r1 adjacent to r0, then there must not exist any read r2 such that r2 has more in common with r0 than r1. This assumes that all reads are total.

Additionally, if the graph is to be… smooth, as opposed to forking, there are only two directions to travel from any given read. This implies there can be at most two reads r1 and r2 with an equal number of links and distinct links to r0. If a third read with this property exists, there’s ‘nowhere to put it’ without creating a fork.

We can verify this property in roughly linear time, which is nice. It doesn’t, however, prevent closed loops with no forking structure.

To do loops, I think we have to actually do the graph traversal. Let’s punt on that for now.