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 08:57:54 GMT
>> The limitation would be on the set of concurrent
>> sessions for which we want to keep track of local commit information
>> for observation.

How this would work in a cluster mode. If two nodes in a cluster
perform commit with (base revision, head revision) [b1,h1] and [b1,h2]
then how would observation work?.

What if we make NodeState implement comparable and then while changing
the ChangeDispatcher.previousRoot do the change only if the new state
is *newer* than previous. Then we would not be seeing duplicate
events. We can do this for Segment and MongoMK as both refer to
linearly increasing recordId/revisionId. H2 MK is anyway single node
and it serializes the writes so it has to be managed through some
mechanism.

Its possible that for a series of changes like [b1,h1] ->[ b1,h2] ->
[h1,h3] the observation logic miss out seeing in between state
transition. But it would effectively see all the changes. Only changes
which get negated between missed transition would not be observed. But
I do not see a way that such losses can be avoided without going for a
linear journal or serializing the complete commit sequences.

regards
Chetan


On Mon, Jul 22, 2013 at 4:45 PM, Michael Dürig <michid@gmail.com> wrote:
> 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