ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dmitriy Setrakyan <dsetrak...@apache.org>
Subject Re: PRIMARY_SYNC+readFromBackup semantics
Date Thu, 05 Oct 2017 05:52:48 GMT
Val, do you have a fix in mind?

On Thu, Oct 5, 2017 at 2:50 AM, Valentin Kulichenko <
valentin.kulichenko@gmail.com> wrote:

> FULL_SYNC as default is not a solution. PRIMARY_SYNC/readFromBackup is
> valid combination of parameters and useful in many scenarios. For example,
> what if I have a replicated cache and don't want to update all nodes
> synchronously?
>
> The point is that get() invoked after the put() in the same thread should
> always return the latest value. Now this behavior is not consistent and
> depends on which nodes these operations are executed on.
>
> -Val
>
> On Wed, Oct 4, 2017 at 3:27 AM, Alexei Scherbakov <
> alexey.scherbakoff@gmail.com> wrote:
>
> > Val,
> >
> > Totally agreed.
> >
> > I think this can be easily fixed by setting FULL_SYNC as default sync
> mode.
> >
> > Actually, I do not understand why this is not done yet.
> >
> > 2017-10-04 12:09 GMT+03:00 Vladislav Pyatkov <vldpyatkov@gmail.com>:
> >
> > > Hi Val,
> > >
> > > If we update local backup immediate synchronously when sending commit
> to
> > > primary, this only partly removes questions about consistence view.
> > > But we always can to get other (unpredictable) value, because another
> > > transaction will be executed simultaneously from other threads.
> > >
> > > At the same time this is good place for optimization, probably reduce
> > > network overhead.
> > > I think, need to create a ticket in Jira for the improvement.
> > >
> > >
> > > On Tue, Oct 3, 2017 at 12:27 AM, Valentin Kulichenko <
> > > valentin.kulichenko@gmail.com> wrote:
> > >
> > > > Igniters,
> > > >
> > > > I noticed that combination of PRIMARY_SYNC mode and
> readFromBackup=true
> > > > (both are default values BTW) introduces weird semantics when reading
> > > *on a
> > > > backup node*. Basically, if I do put and then get for the same key in
> > the
> > > > same thread, I can get previous value. In my understanding, this
> > happens
> > > > because even local backup is updated asynchronously in this case.
> > > >
> > > > First of all, this is obviously confusing and would be considered as
> a
> > > bug
> > > > by most of the users (I just updated the key with some value, why
> > would I
> > > > get another value when reading it?).
> > > >
> > > > Second of all, it seems that we send a network message from primary
> > node
> > > to
> > > > local backup, which doesn't make much sense to me and looks like
> > > > unnecessary performance overhead.
> > > >
> > > > Is it possible to update local backup synchronously in this scenario?
> > > >
> > > > -Val
> > > >
> > >
> > >
> > >
> > > --
> > > Vladislav Pyatkov
> > >
> >
> >
> >
> > --
> >
> > Best regards,
> > Alexei Scherbakov
> >
>

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