jackrabbit-oak-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Dürig <mdue...@apache.org>
Subject Re: Conflict handling causes spurious observation events
Date Mon, 22 Jul 2013 10:35:40 GMT

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.


> BR,
> Jukka Zitting

View raw message