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
I've been thinking about when it's necessary to use vector clocks.
Vector clocks enable you do decide whether two events are concurrent (one cannot have caused the other) or causal.
It depends on how your application handles concurrency. Assuming this is used to track updates to data, then if you have two concurrent updates A,B you merge them into a third update C. so that isCausal(A, C) and isCausal(B, C).
this is a "two way merge" http://en.wikipedia.org/wiki/Merge_%28revision_control%29#Two-way_Merge this will be unreliable if your data structure isn't commutative.
if A, B, C are concurrent merge(merge(A,B), C) MUST equal merge(merge(C,B), A). However, if our updates are commutative, do we still need vector clocks?
I'm not sure that we do, unless users perform the merges. or the merges are performed by a single authority, and not distributed. If a merge is commutative then merge(A, B) == B if isCausal(A, B).
hmm, or is the use case for vector clocks when the merge isn't commutative?
Alternatively, you could use a three way merge, but for this you need the whole histroy of changes so that you can find the common ancestor (or "concestor")
As I see it, is that vector clocks are useful when you need to keep track of events that may be concurrent, but they method for resolving concurrent changes is left unspecified by the system (as how dynamo leaves merges up to the application)
The merge doesn't necessarily need to be commutative, because you will still get eventual consistency by propagating the arbitrary merge.
I think I've answered my own question by writing this issue, what do you think?
The text was updated successfully, but these errors were encountered:
I've been thinking about when it's necessary to use vector clocks.
Vector clocks enable you do decide whether two events are concurrent (one cannot have caused the other) or causal.
It depends on how your application handles concurrency. Assuming this is used to track updates to data, then if you have two concurrent updates A,B you merge them into a third update C. so that
isCausal(A, C)
andisCausal(B, C)
.this is a "two way merge" http://en.wikipedia.org/wiki/Merge_%28revision_control%29#Two-way_Merge this will be unreliable if your data structure isn't commutative.
if A, B, C are concurrent
merge(merge(A,B), C)
MUST equalmerge(merge(C,B), A)
. However, if our updates are commutative, do we still need vector clocks?I'm not sure that we do, unless users perform the merges. or the merges are performed by a single authority, and not distributed. If a merge is commutative then merge(A, B) == B if isCausal(A, B).
hmm, or is the use case for vector clocks when the merge isn't commutative?
Alternatively, you could use a three way merge, but for this you need the whole histroy of changes so that you can find the common ancestor (or "concestor")
As I see it, is that vector clocks are useful when you need to keep track of events that may be concurrent, but they method for resolving concurrent changes is left unspecified by the system (as how dynamo leaves merges up to the application)
The merge doesn't necessarily need to be commutative, because you will still get eventual consistency by propagating the arbitrary merge.
I think I've answered my own question by writing this issue, what do you think?
The text was updated successfully, but these errors were encountered: