jackrabbit-oak-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Dürig <mic...@gmail.com>
Subject Re: Conflict handling causes spurious observation events
Date Mon, 22 Jul 2013 11:15:44 GMT
On 22.7.13 12:48, Jukka Zitting wrote:
> Hi,
>
> On Mon, Jul 22, 2013 at 1:35 PM, Michael Dürig <mduerig@apache.org> wrote:
>> 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.
>
> Note that the extra synchronization here would only hurt single-node
> concurrency, not horizontal scalability across cluster nodes. I.e. it
> would still be possible for two cluster nodes (even two
> repository/KernelNodeStore instances in the same JVM) to commit
> concurrently. The limitation would be on the set of concurrent
> sessions for which we want to keep track of local commit information
> for observation.

Right and for the latter case there is also the option of using
SegmentMK, which doesn't suffer from this. For the Microkernel based
implementation we can reconsider further optimisations if it turns out
we need to improve per cluster node session concurrency.

Going forward I will therefore:
- move the post commit hook to NodeStoreBranch.merge,
- leverage its rebasing capability in the case of SegementMK,
- explicitly synchronise in the case of the MircorKernel based
implementations.

Michael

>
> BR,
>
> Jukka Zitting
>

Mime
View raw message