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: product_docs/docs/pgd/5/durability/comparing-commit-scopes.mdx
+2-2Lines changed: 2 additions & 2 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -31,7 +31,7 @@ We will look at the state of each kind, before and after connectivity is restore
31
31
32
32
With Group Commit and before restoration, the origin node will have prepared a transaction and wait for confirmations which will not arrive.
33
33
It could timeout and abort the transaction or just wait if the timeout setting is long enough.
34
-
Writes that are recieved by the replicas will be held back if the nodes have prepared transactions from the now-disconnected origin. If there are no prepared transactions, they can continue to recieve writes.
34
+
Writes that are recieved by the replicas will be held back if the nodes have prepared transactions from the now-disconnected origin and they hold conflicting locks. If there are no conflicts, they can continue to recieve writes.
35
35
36
36
When connectivity is restored, eventually where the origin node aborted the transaction, the prepared transaction on some or all of the replicas will follow in aborting the transaction.
37
37
If there are prepared transactions on all nodes, including the origin, the reconciliation process will commit them. Until that happens, each prepared transaction will be holding locks that will prevent nodes that have resumed writing from overwriting the transaction's writes from other nodes
@@ -42,7 +42,7 @@ With Synchronous Commit and before restoration, the origin node will have commit
42
42
The client may cancel it or it could timeout, but the transaction stays committed on this node.
43
43
On the other side of the partition, it's possible that one of the replicas becomes write leader and that segment of the cluster starts writing to the other nodes.
44
44
45
-
As the network restores, and if the commit hasn't reached the other nodes, it is possible that the writes on the non-origin side could conflict with the writes from the origin node. The default async conflict resolution may choose one over the other and give errors or potential inconsistencies.
45
+
As the network restores, and the commit from the separated origin arrives, it could conflict with the writes from the other nodes. The default async conflict resolution may choose one over the other which could give errors or potential inconsistencies.
0 commit comments