1. Serializable
Same results as if transactions executed one-by-one.
Even though they may actually execute concurrently.
r/w transactions are serializable
implemented through 2PL
r/o transactions fit between r/w transactions
assign each transaction a timestamp
use timestamped snapshots to ensure this. lock-free.
a r/o transaction can see result of all commited r/w transactions whose timestamps are lower than timestamp of the r/o transaction
Example 1
T1: Wx Wy C
T2: Wx Wy C
T3: Rx Ry
if T3 reads the latest value of x and y respectively, the transaction history can not be serializable. Read skew occurs in T3.
Example 2 (Snapshot Isolation)
x@10=9 x@20=8 version history of x
y@10=11 y@20=12 version history of y
T1 @ 10: Wx Wy C
T2 @ 20: Wx Wy C
T3 @ 15: Rx Ry
"@ 10" indicates the timestamp of T1 is 10.
T3 will see x@10=9, y@10=11
Example 3 (Snapshot Isolation)
x@10=9
y@10=11 y@14=12
T1 @ 10: Wx Wy C
T2 @ 14: Wy C
T3 @ 15: Rx Ry
T3 will see x@10=9, y@14=12
2. Externally Consistent
If T1 completes before T2 starts (in real time), T2 must see T1's writes.
External consistency rules out reading stale data
Implementation
we want to ensure that
if T1 commits before T2 starts, T1's timestamp TS1 < T2's timestamp TS2
so we can ensure serializability and external consistency all together using timestamps
Assign timestamp TS of a r/w transaction T to TT.now().latest when it is ready to commit
a r/w transaction T must wait until TS < TT.now().earlist before commit (commit wait)
If T1 commits before T2 starts (in real time), and T1 is a r/w transaction
assign TS1 to TT.now().latest when T1 is ready to commit
if T2 is also a r/w transactions,
assign TS2 to TT.now().latest when T2 is ready to commit
then:
real time of T1's commit < real time of T2's start (assumption)
TS1 < real time of T1's commit (commit wait)
TS2 >= real time of event of TS2's assignment >= real time of T2's start
=> TS1 < TS2
if T2 is a r/o transaction
assign TS2 to TT.now().latest when T2 starts
then:
real time of T1's commit < real time of T2's start (assumption)
TS1 < real time of T1's commit (commit wait)
TS2 >= real time of event of TS2's assignment >= real time of T2's start
=> TS1 < TS2
T2 can perform reads to data whose timestamp less than TS2, so that T2 can see writes of r/w transactions that commit before T2 starts
Is it possible that TS1 < TS2 and T1 commits after T2 starts ?
Yes. In this case, T2 will also see T1's writes
External consistency says nothing about the case that T1 commits after T2 starts
In the Spanner paper, we know that r/o transactions can read at any replica, how to ensure that a r/o transaction T sees all writes of r/w transactions whose timestamp < TS ?
Safe wait. Before serving a read with timestamp TS, replica must ensure that there will be no writes whose timestamp < TS commits at the replica.
If the replica see a Paxos write whose timestamp >= TS, there will be no writes whose timestamp < TS due to the timestamp monotonicity invariant:
within each Paxos group, Spanner assigns timestamps to Paxos writes in monotonically increasing order
so it is safe to serve the read.
But what if there are no such writes in a relatively long time?
the read will be blocked and the latency will be high.
Solution:
if there are no prepared transaction seen by the replica, the reader must wait.
if the replica knows a lower bound on timestamps of any prepared but not yet commited transactions
Spanner ensures that commit timestamp of such a transaction >= the known lower bound
So if the lower bound >= TS2, read can be safely served
Note:
Internal consistency: within a transaction, reads observe that transaction’s most recent writes (if any)
External consistency: reads without a preceding write in transaction T1 must observe the state written by a transaction T0, such that T0 is visible to T1, and no more recent transaction wrote to that object.
Spanner does not guarantee internal consistency.
References
Spanner: Google’s Globally-Distributed Database [OSDI 2012]
JEPSEN Blog: Snapshot Isolation