ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Semyon Boikov <sboi...@gridgain.com>
Subject Re: MVCC configuration
Date Tue, 19 Sep 2017 09:25:04 GMT
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 <vozerov@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 <sboikov@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 <vozerov@gridgain.com>
> > wrote:
> >
> > > This could be something like "preferredMvccCoordinator".
> > >
> > > On Tue, Sep 19, 2017 at 10:40 AM, Alexey Goncharuk <
> > > alexey.goncharuk@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.
> > > >
> > >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message