jackrabbit-oak-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chetan Mehrotra <chetan.mehro...@gmail.com>
Subject Re: Conflict handling causes spurious observation events
Date Tue, 23 Jul 2013 10:26:17 GMT
> 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 <jukka.zitting@gmail.com> wrote:
> Hi,
>
> On Tue, Jul 23, 2013 at 12:47 PM, Chetan Mehrotra
> <chetan.mehrotra@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

Mime
View raw message