Still trying to grok vector clocks, here's a question.
When riak realizes that two peers did successfully update the same key, those
two riak_object's will have different (one not deriving from the other) vector
clocks. This could happen when e.g. synchronizing using long-haul replication.
When these are then consolidated into a single multi-valued object, how is the
vector clock of the resulting object computed?
In other words, why does it keep the two vclocks, one per value?
I would think that a riak_object should be structured thus:
object ::= { bucket, key, [ vclock x value ] }
But, it is structured like this:
object ::= { bucket, key, vclock, [ value ] }
This structure implies that a new vclock is computed by an agent doing the
merge [involving a client id of that agent], but what happens if two agents
independently realizes the conflict and tries to do the merge? Will those two
independent merges have conflicting vector clocks?
So why not keep both vector clocks around, so that independent agents can do
merges that will then be conciliable because no new information is created when
merging?
Kresten
_______________________________________________
riak-users mailing list
[email protected]
http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
