>> 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 <mic...@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 <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 >>
