What I mean is that it might be not applicable for DML by design. E.g. may be we will have to fallback to per-memory-policy approach, or to per-cache-group. As we do not know it at the moment and there is no clear demand from users, I would simply put it aside to avoid in mess in public API in future.
Moreover, per-cache flag raises additional questions which can be put out of scope otherwise. E.g. is it legal to mix MVCC and non-MVCC caches in a single transaction? If yes, what is the contract? Without fine-grained per-cache approach in the first iteration we can avoid answering it. On Tue, Sep 19, 2017 at 12:25 PM, Semyon Boikov <sboi...@gridgain.com> wrote: > 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. > > > > > > > > > > > > > > >
