I would say that per-cache configuration should be out of scope as well for the first iteration. Because we do not know whether it will be valid for DML.
On Tue, Sep 19, 2017 at 12:15 PM, Semyon Boikov <sboi...@gridgain.com> wrote: > 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 <voze...@gridgain.com> > wrote: > > > This could be something like "preferredMvccCoordinator". > > > > On Tue, Sep 19, 2017 at 10:40 AM, Alexey Goncharuk < > > alexey.goncha...@gmail.com> 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. > > > > > >
