From 1d101c024c0aeb827c3dc0b179dd2ecb5516612e Mon Sep 17 00:00:00 2001
From: "Peter J. Keleher" <keleher@cs.umd.edu>
Date: Thu, 9 Dec 2021 10:09:18 -0500
Subject: [PATCH] auto
---
notes/hat.md | 30 ++++++++++++------------------
1 file changed, 12 insertions(+), 18 deletions(-)
diff --git a/notes/hat.md b/notes/hat.md
index b49a785..ac21a0c 100644
--- a/notes/hat.md
+++ b/notes/hat.md
@@ -81,7 +81,7 @@ guarantees. Assume invariant *x == y*:
Both preserve consistency in isolation, but not w/ this schedule and dirty writes.
-## Isolation guarantee definitions:
+## Achievable isolation levels with partitions
"**read uncommitted**" (PL-1)
- writes to each obj totally ordered (prohibits dirty writes)
@@ -100,12 +100,12 @@ Both preserve consistency in isolation, but not w/ this schedule and dirty write
- **item cut isolation**
- multiple different values
- implement by buffering reads
-- **predicate cut isolation*
+- **predicate cut isolation**
- cut over "SELECT ..WHERE....") (phantom anomalies)
- implement by caching entire logical ranges
----
-### Unachievable isolation levels with partitions:
+## Unachievable isolation levels with partitions
- snapshot isolation,
- read from consistent cut
- commit only if items from writeset not committed by another T since snapshot
@@ -116,6 +116,10 @@ Both preserve consistency in isolation, but not w/ this schedule and dirty write
on entire set of results
- violated if lost writes because of locks not reaching across partition.
- therefore not HAT (because can't prevent lost updates)
+- Serializability:
+ - optimistic requires global validation
+ - pessimistic requires global coord/locking
+
----
### Unachievable properties
- preventing lost updates
@@ -129,27 +133,17 @@ Both preserve consistency in isolation, but not w/ this schedule and dirty write
*Clearly impossible to prevent in dist environment.*
-- preventing write skew. Write Skew generalizes LU to multiple keys. Possible problem is
-violation of consistency, such as "x == y""
+- preventing write skew.
+ - generalizes *lost updates* to multiple keys
+ - problem is possible violation of *consistency* (different Tx effective
+ access distinct replicas)
+ - initially X = 1, Y = 2, each transaction trying to make them identical.
```
T1: t = x; y = t
T2: t = y; x = t
```
Can happen w/ snapshot isolation even w/o partitions.
-- Serializability:
- - optimistic requires global validation
- - pessimistic requires global coord/locking
-
-
-
-- Katura not buying sticky avail (definitional)
-- Nao - "really confusing" (yes)
-- Patrick/Andrew - causal only w/ sticky (client caching breaks lots of guarantees)
-
-
-
-----
### HAT-compliant:
--
GitLab