Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

vector clocks: when to use? #2

Open
dominictarr opened this issue Sep 23, 2012 · 0 comments
Open

vector clocks: when to use? #2

dominictarr opened this issue Sep 23, 2012 · 0 comments

Comments

@dominictarr
Copy link

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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant