ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vladimir Ozerov <voze...@gridgain.com>
Subject Re: Set default cache synchronization mode to FULL_SYNC
Date Wed, 02 Aug 2017 18:30:52 GMT
Not sure about readFromBackup, but changing PRIMARY_SYNC to FULL_SYNC looks
safe to me. Any other thoughts?

ср, 2 авг. 2017 г. в 21:10, Denis Magda <dmagda@apache.org>:

> +1 for both suggestions but I’m not sure we can do the change till 3.0.
>
> —
> Denis
>
> > On Aug 2, 2017, at 1:27 AM, Vladimir Ozerov <vozerov@gridgain.com>
> wrote:
> >
> > +1 for readFromBackup=false as well :-) Another example of default value
> > with subtle effects.
> >
> > On Wed, Aug 2, 2017 at 11:11 AM, Alexey Goncharuk <
> > alexey.goncharuk@gmail.com> wrote:
> >
> >> Vladimir,
> >>
> >> Personally, I agree that we should put correctness over performance,
> >> however (1) is not a correct statement for TRANSACTIONAL caches. A
> >> transactional client always validates the result of an operation and
> throw
> >> a correct exception if operation failed. (1) is true for ATOMIC caches,
> >> though.
> >>
> >> A user can get in trouble in this default for both TX and ATOMIC caches
> if
> >> a put is performed from a backup node and readFromBackup is set to
> false.
> >> In this case, the simple read-after-write scenario may fail. I would
> rather
> >> set readFromBackup to false by default, however, this fixes neither the
> SQL
> >> nor ATOMIC caches issues.
> >>
> >> +1 for the change, and extend the warning for partitioned caches with
> >> readFromBackup=true and PRIMARY_SYNC.
> >>
> >>
> >>
> >> 2017-08-02 10:58 GMT+03:00 Vladimir Ozerov <vozerov@gridgain.com>:
> >>
> >>> Igniters,
> >>>
> >>> I want to re-iterate idea of changing default synchronization mode from
> >>> PRIMARY_SYNC to FULL_SYNC.
> >>>
> >>> Motivation:
> >>> 1) If user set [cacheMode=PARTITIONED, backups=1] he still could loose
> >> data
> >>> silently. Because primary node could report success to the client and
> >> then
> >>> crash before data is propagated to backups.
> >>> 2) If user set [cacheMode=REPLICATED] and use SQL, he will might get
> >>> invalid results if cache is being updated concurrently - well known
> >> issue.
> >>>
> >>> The only advantage of PRIMARY_SYNC is slightly better performance, but
> we
> >>> should prefer correctness over performance.
> >>>
> >>> Proposed changes:
> >>> 1) Make FULL_SYNC default;
> >>> 2) Print a warning about possibly incorrect SQL results if REPLICATED
> >> cache
> >>> is started in PRIMARY_SYNC mode.
> >>>
> >>> Thoughts?
> >>>
> >>> Vladimir.
> >>>
> >>
>
>

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