You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: en-us/ch7.md
+6-6
Original file line number
Diff line number
Diff line change
@@ -53,27 +53,27 @@ In this chapter, we went particularly deep into the topic of concurrency control
53
53
54
54
***Dirty reads***
55
55
56
-
One client reads another client’s writes before they have been committed. The read committed isolation level and stronger levels prevent dirty reads.
56
+
One client reads another client’s writes before they have been committed. The read committed isolation level and stronger levels prevent dirty reads.
57
57
58
58
***Dirty writes***
59
59
60
-
One client overwrites data that another client has written, but not yet committed. Almost all transaction implementations prevent dirty writes.
60
+
One client overwrites data that another client has written, but not yet committed. Almost all transaction implementations prevent dirty writes.
61
61
62
62
***Read skew (nonrepeatable reads)***
63
63
64
-
A client sees different parts of the database at different points in time. This issue is most commonly prevented with snapshot isolation, which allows a transaction to read from a consistent snapshot at one point in time. It is usually implemented with *multi-version concurrency control* (MVCC).
64
+
A client sees different parts of the database at different points in time. This issue is most commonly prevented with snapshot isolation, which allows a transaction to read from a consistent snapshot at one point in time. It is usually implemented with *multi-version concurrency control* (MVCC).
65
65
66
66
***Lost updates***
67
67
68
-
Two clients concurrently perform a read-modify-write cycle. One overwrites the other’s write without incorporating its changes, so data is lost. Some implemen‐ tations of snapshot isolation prevent this anomaly automatically, while others require a manual lock (SELECT FOR UPDATE).
68
+
Two clients concurrently perform a read-modify-write cycle. One overwrites the other’s write without incorporating its changes, so data is lost. Some implemen‐ tations of snapshot isolation prevent this anomaly automatically, while others require a manual lock (SELECT FOR UPDATE).
69
69
70
70
***Write skew***
71
71
72
-
A transaction reads something, makes a decision based on the value it saw, and writes the decision to the database. However, by the time the write is made, the premise of the decision is no longer true. Only serializable isolation prevents this anomaly.
72
+
A transaction reads something, makes a decision based on the value it saw, and writes the decision to the database. However, by the time the write is made, the premise of the decision is no longer true. Only serializable isolation prevents this anomaly.
73
73
74
74
***Phantom reads***
75
75
76
-
A transaction reads objects that match some search condition. Another client makes a write that affects the results of that search. Snapshot isolation prevents straightforward phantom reads, but phantoms in the context of write skew require special treatment, such as index-range locks.
76
+
A transaction reads objects that match some search condition. Another client makes a write that affects the results of that search. Snapshot isolation prevents straightforward phantom reads, but phantoms in the context of write skew require special treatment, such as index-range locks.
Copy file name to clipboardExpand all lines: en-us/ch9.md
+6-6
Original file line number
Diff line number
Diff line change
@@ -41,27 +41,27 @@ We saw that achieving consensus means deciding something in such a way that all
41
41
42
42
***Linearizable compare-and-set registers***
43
43
44
-
The register needs to atomically *decide* whether to set its value, based on whether its current value equals the parameter given in the operation.
44
+
The register needs to atomically *decide* whether to set its value, based on whether its current value equals the parameter given in the operation.
45
45
46
46
***Atomic transaction commit***
47
47
48
-
A database must *decide* whether to commit or abort a distributed transaction.
48
+
A database must *decide* whether to commit or abort a distributed transaction.
49
49
50
50
***Total order broadcast***
51
51
52
-
The messaging system must *decide* on the order in which to deliver messages.
52
+
The messaging system must *decide* on the order in which to deliver messages.
53
53
54
54
***Locks and leases***
55
55
56
-
When several clients are racing to grab a lock or lease, the lock *decides* which one successfully acquired it.
56
+
When several clients are racing to grab a lock or lease, the lock *decides* which one successfully acquired it.
57
57
58
58
***Membership/coordination service***
59
59
60
-
Given a failure detector (e.g., timeouts), the system must *decide* which nodes are alive, and which should be considered dead because their sessions timed out.
60
+
Given a failure detector (e.g., timeouts), the system must *decide* which nodes are alive, and which should be considered dead because their sessions timed out.
61
61
62
62
***Uniqueness constraint***
63
63
64
-
When several transactions concurrently try to create conflicting records with the same key, the constraint must *decide* which one to allow and which should fail with a constraint violation.
64
+
When several transactions concurrently try to create conflicting records with the same key, the constraint must *decide* which one to allow and which should fail with a constraint violation.
0 commit comments