Skip to content
Snippets Groups Projects
Commit 3308117c authored by Peter J. Keleher's avatar Peter J. Keleher
Browse files

auto

parent 0a537513
No related branches found
No related tags found
No related merge requests found
......@@ -11,30 +11,29 @@ Correctness anomalies
- 1SR “one-copy serializability”
- any read will return the most recent write to that data item, regardless of which replicas are read or written
- doesn’t fix all problems
-
## The Anomalies
the immortal write -
*the immortal write* -
![](https://paper-attachments.dropbox.com/s_9C40D1E627431C359DFC050423F865DB110CEF11D9FA101F15E75C20CDD3C4D3_1639005186338_image.png)
- tempting to leverage time travel to create an immortal blind write, which enables strightforward conflict resolution without violating the serializability guarantee
the stale read
*the stale read* -
![](https://paper-attachments.dropbox.com/s_9C40D1E627431C359DFC050423F865DB110CEF11D9FA101F15E75C20CDD3C4D3_1639005248966_image.png)
- in single-server system little incentive to read older versions
- in distributed system, most recent version costs latency
the causal reverse
*the causal reverse* -
![](https://paper-attachments.dropbox.com/s_9C40D1E627431C359DFC050423F865DB110CEF11D9FA101F15E75C20CDD3C4D3_1639023882254_image.png)
- serialization order doesn’t respect potential causality of non-conflicting writes (to different data, for example)
SumUp
### SumUp
- all can occur in 1SR
- none occur w/ strict serializability,
......@@ -43,14 +42,13 @@ SumUp
# Highly Available
```
authors: Peter Bailis, Alan Fekete, Ali Ghodsi, Joseph M. Hellerstein, Ion Stoica
title: "HAT, not CAP: Towards Highly Available Transactions"
where: HotOS 2013
```
### Definitions, in the context of Partitions:
### Definitions
- **high availability:**
- each user that can contact a non-failing server eventually receives
......@@ -72,7 +70,7 @@ SumUp
```
Read should not ever return '1', and shouldn't return '3' if T2 aborts
"**dirty writes**"
- "**dirty writes**"
A *dirty write* occurs when one transaction overwrites a value that has previously been
written by another still in-flight transaction. Why bad? Could violate consistency
guarantees. Assume invariant *x == y*:
......@@ -100,7 +98,7 @@ Both preserve consistency in isolation, but not w/ this schedule and dirty write
- impl both w/ buffering
----
### Unachievable isolation levels
### Unachievable isolation levels with partitions:
- snapshot isolation,
- read from consistent cut
- commit only if items from writeset not committed by another T since snapshot
......@@ -130,7 +128,7 @@ violation of consistency, such as "x == y""
T1: t = x; y = t
T2: t = y; x = t
```
Can happen w/ snapshot isolation.
Can happen w/ snapshot isolation even w/o partitions.
- Serializability:
- optimistic requires global validation
......@@ -148,6 +146,11 @@ Can happen w/ snapshot isolation.
### HAT-compliant:
![pic](hat.png)
![pic](hat1.png)
### Partial ordering
![pic](hat2.png)
- Blue is sticky available
- Red is unavailable
----
notes/hat1.png

181 KiB

notes/hat2.png

159 KiB

0% Loading or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment