Can caches within the same group have different MVCC configuration? On Tue, Sep 19, 2017 at 2:34 AM, Vladimir Ozerov <voze...@gridgain.com> wrote:
> 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. > > > > > > > > > > > > > > > > > > > > >
