If it is not valid for DML then we can easily detect this situation and throw exception, but if I do not use DML why non make it configurable per-cache?
On Tue, Sep 19, 2017 at 12:22 PM, Vladimir Ozerov <voze...@gridgain.com> wrote: > 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. > > > > > > > > > >
