On 22.7.13 12:05, Jukka Zitting wrote:
Hi,
On Fri, Jul 19, 2013 at 7:00 PM, Michael Dürig <mdue...@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
