Hi, On Tue, Jul 23, 2013 at 12:47 PM, Chetan Mehrotra <chetan.mehro...@gmail.com> wrote: >> The end result in either case is a sequence of events from b1 to h3. > > If this is fine (and something which cannot be avoided) then cannot we
In general that can't be avoided in a fully distributed case. > just make the NodeState comparable and avoid synchronizing the merge? > As that still allows us to see an ordered flow of changes. The problem why we can't just do as you suggest is that there's no way to (scalably) attach accurate user information (who committed this change) to merges like h3, which leads to backwards compatibility issues for observation (see https://issues.apache.org/jira/browse/OAK-775). The compromise we came up with in OAK-775 is to maintain such information for local events (i.e. b1->h1 for node A and b1->h2 for node B), but not for events originating from the rest of the cluster (i.e. h1->h3 and h2->h3). BR, Jukka Zitting
