Mailing-List: contact oak-dev-help@jackrabbit.apache.org; run by ezmlm
Precedence: bulk
Reply-To: oak-dev@jackrabbit.apache.org
Received-SPF: error (athena.apache.org: local policy)
Message-ID: <51ED0AFC.5080901@apache.org>
Date: Mon, 22 Jul 2013 12:35:40 +0200
From: =?ISO-8859-1?Q?Michael_D=FCrig?= <mduerig@apache.org>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7;
 rv:17.0) Gecko/20130620 Thunderbird/17.0.7
MIME-Version: 1.0
To: oak-dev@jackrabbit.apache.org
Subject: Re: Conflict handling causes spurious observation events
References: <51E962BA.7040903@apache.org>
 <CAOFYJNZSqW_bvJdXHs8pce+5iNKAx_AP=Q3hJyK4f0Si7E7VXw@mail.gmail.com>
In-Reply-To: 
 <CAOFYJNZSqW_bvJdXHs8pce+5iNKAx_AP=Q3hJyK4f0Si7E7VXw@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit


On 22.7.13 12:05, Jukka Zitting wrote:
> Hi,
>
> On Fri, Jul 19, 2013 at 7:00 PM, Michael D�rig <mduerig@apache.org> wrote:
>> Chetan discovered that in some cases spurious observation events would be
>> created when to sessions save concurrently. In a nutshell the problem occurs
>> since the current implementation of observation [1] expects a linear
>> sequence of revisions (per cluster node). However on Root.commit there is a
>> small race between rebasing and merging a branch: when another session saves
>> inside this time frame, its branch will have the same base revision like
>> that of the former session. In this case the sequence of revisions is
>> effectively non linear.
>
> If we move the logic from Root.commit() to NodeStoreBranch.merge(), we
> should be able to prevent concurrent updates either by leveraging the
> internal rebase logic in SegmentMK or by synchronizing on the
> associated NodeStore instance.

Yes I was thinking of something similar. For this to work we need to 
pass the post commit hook to NSB.merge().

I noticed that the SegmentMK handles this situation correctly. That is, 
it rebases before running the hooks and re-runs the hooks in case of a 
failure. It even incorporate some logic to fall back to pessimistic 
locking when optimistic locking fails.

So moving the post commit hook to NSB.merge() should solve the problem 
when using the SegmentMK.

For other NodeStore implementations I currently don't see how to reuse 
the code from SegmentMK without changing the contract of the 
Microkernel.merge method. As long as that method does its own merge 
magic we need to prevent concurrent merges in order to avoid the race 
condition. This means we'd need to synchronise on the NodeStore instance 
as you mention. But AFAIR we explicitly wanted to avoid this for 
scalability reasons.

Michael

>
> BR,
>
> Jukka Zitting
>