From 104a2773a7e87ed817d73105e9b77355c45e3d14 Mon Sep 17 00:00:00 2001
From: "Peter J. Keleher" <keleher@cs.umd.edu>
Date: Tue, 16 Nov 2021 10:27:06 -0500
Subject: [PATCH] auto

---
 notes/spannerCockroach.md | 25 ++++++++++++++++---------
 1 file changed, 16 insertions(+), 9 deletions(-)

diff --git a/notes/spannerCockroach.md b/notes/spannerCockroach.md
index 7fe8714..e59c05a 100644
--- a/notes/spannerCockroach.md
+++ b/notes/spannerCockroach.md
@@ -110,17 +110,20 @@ external consistency known as “linearizability.”
 - "in a non-distributed database, serializability implies linearizability"
   - single clock
   - if T2 starts after T1 finishes, that will be equiv serial order, and so...
-![blah](cockroachUnsync.png)
 - "CockroachDB’s external consistency guarantee is by default only
   serializability, though with some features that can help bridge the gap in
   practice."
   
+  The anomaly of "causal reverse":
+  ![blah](cockroachUnsync.png)
+
+TrueTime gives clocks skew upper bound of 7ms (as opposed to 100-250ms).
   
 "Before a node is allowed to report that a transaction has committed, it must
-wait 7ms. Because all clocks in the system are within 7ms of each other,
+wait 7ms. **Because all clocks in the system are within 7ms of each other,
 waiting 7ms means that no subsequent transaction may commit at an earlier
-timestamp, even if the earlier transaction was committed on a node with a
-clock which was fast by the maximum 7ms"
+timestamp**, even if the earlier transaction was committed on a node with a
+clock which was fast by the maximum 7ms."
 
 Approach:
 - "The possibility of reordering commit timestamps for causally related
@@ -129,17 +132,19 @@ Approach:
 - "What *could* happen is that examining the database at a historical timestamp
   might yield paradoxical situations where transaction A is not yet visible
   while transaction B is, even though transaction A is known to have preceded
-  B, as they’re causally related. However, this can only happen if there’s no
-  overlap between the keys read or written during the transactions."
+  B, as they’re causally related. However, **this can only happen if**:
+  - there’s no overlap between the keys read or written during the transactions.
+  - there’s an external low-latency communication channel between clients that
+    could potentially impact activity on the DBMS. 
 
 ## Approach
 
 **causality token** - max timestamp encountered (anywhere) in a transaction.
 - used to ensure that causal chains maintained by serving as minimum commit
   timestamp for that transaction.
+- doesn't help w/ independent causal chains
   
-  
-**Problem:**
+**Another Problem:**
 - *Ti* reading data from mult nodes might fail to read already-committed data
 
 **Solution:**
@@ -158,7 +163,9 @@ Approach:
 
 So: 
 - spanner always short-waits on writes for short interval (~7ms)
-- cockroachdb sometimes long waits on reads (~250ms)
+- cockroachdb delay:
+  - often fast (one or two rounds, maybe 5ms)
+  - sometimes long waits on reads (~250ms)
 - causal reverse still possible (though probably not a problem in practice)
 
 Strict serializability makes all of the guarantees of one-copy serializability
-- 
GitLab