> 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).
Okie now I understand. Missed reading that discussion as I was on leave. So for external event we do not have to provide the user and date information. In discussion referred to in OAK-775 it was mentioned that the event processing would be pluggable. Is that still the case? If we make the merge method synchronized then it cannot be avoided through a different PostCommitHook implementation We can possibly persist only the metadata associated with tuple (baseRevision,headRevision) and refer to that for providing information regarding the metadata. This would avoid duplicating the complete content. And with use of Mongo capped collections [1] can be easily implemented [1] http://docs.mongodb.org/manual/core/capped-collections/ Chetan Mehrotra On Tue, Jul 23, 2013 at 3:30 PM, Jukka Zitting <[email protected]> wrote: > Hi, > > On Tue, Jul 23, 2013 at 12:47 PM, Chetan Mehrotra > <[email protected]> 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
