ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Дмитрий Рябов <somefire...@gmail.com>
Subject Re: Set default cache synchronization mode to FULL_SYNC
Date Fri, 04 Aug 2017 11:50:19 GMT
I mean "set readFromBackup = false" (copy-paste was bad idea).

2017-08-04 14:21 GMT+03:00 Дмитрий Рябов <somefireone@gmail.com>:

> +1 to change PRIMARY_SYNC to FULL_SYNC.
>
> I think it is not reasonable to set readFromBackup=true by default,
> especially for replicated caches, but FULL_SYNCE will keep cache in
> consistent state.
>
> 2017-08-04 13:23 GMT+03:00 Anton Vinogradov <avinogradov@gridgain.com>:
>
>> +1 to change PRIMARY_SYNC to FULL_SYNC and keep readFromBackup=true
>>
>> Dmitriy,
>> Why should we wait for 3.0?
>> This change looks safe for me.
>>
>> On Wed, Aug 2, 2017 at 9:51 PM, Dmitriy Setrakyan <dsetrakyan@apache.org>
>> wrote:
>>
>> > We have to wait with any default changes to 3.0, unfortunately.
>> >
>> > On Wed, Aug 2, 2017 at 8:30 PM, Vladimir Ozerov <vozerov@gridgain.com>
>> > wrote:
>> >
>> > > 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