On 22.7.13 12:48, Jukka Zitting wrote:
Hi,
On Mon, Jul 22, 2013 at 1:35 PM, Michael Dürig <mdue...@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
