Folks, thank you for feedback, I want to summarize some decisions: 1. Mvcc is disabled by default. We'll add two flags to enable mvcc: per-cache flag - CacheConfiguration.isMvccEnabled, default value for all caches - IgniteConfiguration.isMvccEnabled. 2. For initial implementation mvcc for ATOMIC cache is out of scope, it can be enabled only for TRANSACTIONAL caches. 3. Mvcc coordinator can be any server node (oldest server node is selected automatically). Also I believe we need possibility to have *dedicated* mvcc coordinator nodes which will process only internal mvcc messages. Node can be marked as dedicated coordinator via new flag IgniteConfiguration.isMvccCoordinator or we can add separate MvccConfiguration bean. But let's skip this decision for now before we have benchmarks numbers. 4. Need add some metrics to monitor mvcc coordinator performance.
Thanks On Tue, Sep 19, 2017 at 10:47 AM, Vladimir Ozerov <[email protected]> wrote: > This could be something like "preferredMvccCoordinator". > > On Tue, Sep 19, 2017 at 10:40 AM, Alexey Goncharuk < > [email protected]> wrote: > > > > > > > I agree that we need coordinator nodes, but I do not understand why > can't > > > we reuse some cache nodes for it? Why do we need to ask user to start > up > > > yet another type of node? > > > > > > > Dmitriy, > > > > My understanding is that Semyon does not deny a cache node to be used as > a > > coordinator. This property will allow to optionally have a *dedicated* > node > > serving as a coordinator to improve cluster throughput under heavy load. > > >
