Set default cache synchronization mode to FULL_SYNC

[Vladimir Ozerov]

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.

[Alexey Goncharuk]

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 <[hidden email]>:

> 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.
>

[Vladimir Ozerov]

+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 <
[hidden email]> 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 <[hidden email]>:
>
> > 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.
> >
>

[dmagda]

+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 <[hidden email]> 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 <
> [hidden email]> 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 <[hidden email]>:
>>
>>> 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.
>>>
>>

[Vladimir Ozerov]

Not sure about readFromBackup, but changing PRIMARY_SYNC to FULL_SYNC looks
safe to me. Any other thoughts?

ср, 2 авг. 2017 г. в 21:10, Denis Magda <[hidden email]>:

> +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 <[hidden email]>
> 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 <
> > [hidden email]> 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 <[hidden email]>:
> >>
> >>> 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.
> >>>
> >>
>
>

[dsetrakyan]

We have to wait with any default changes to 3.0, unfortunately.

On Wed, Aug 2, 2017 at 8:30 PM, Vladimir Ozerov <[hidden email]>
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 <[hidden email]>:
>
> > +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 <[hidden email]>
> > 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 <
> > > [hidden email]> 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 <[hidden email]>:
> > >>
> > >>> 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.
> > >>>
> > >>
> >
> >
>

[Anton Vinogradov]

+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 <[hidden email]>
wrote:

> We have to wait with any default changes to 3.0, unfortunately.
>
> On Wed, Aug 2, 2017 at 8:30 PM, Vladimir Ozerov <[hidden email]>
> 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 <[hidden email]>:
> >
> > > +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 <[hidden email]>
> > > 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 <
> > > > [hidden email]> 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 <[hidden email]>:
> > > >>
> > > >>> 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.
> > > >>>
> > > >>
> > >
> > >
> >
>

[Dmitrii Ryabov]

+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 <[hidden email]>:

> +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 <[hidden email]>
> wrote:
>
> > We have to wait with any default changes to 3.0, unfortunately.
> >
> > On Wed, Aug 2, 2017 at 8:30 PM, Vladimir Ozerov <[hidden email]>
> > 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 <[hidden email]>:
> > >
> > > > +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 <[hidden email]>
> > > > 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 <
> > > > > [hidden email]> 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 <[hidden email]
> >:
> > > > >>
> > > > >>> 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.
> > > > >>>
> > > > >>
> > > >
> > > >
> > >
> >
>

[Anton Vinogradov]

Dmitriy,

> 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.

readFromBackup=true allows you to read from backup instead of making
request to primary node,
so it should be useful, especially for replicated cache.

On Fri, Aug 4, 2017 at 2:21 PM, Дмитрий Рябов <[hidden email]> wrote:

> +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 <[hidden email]>:
>
> > +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 <[hidden email]
> >
> > wrote:
> >
> > > We have to wait with any default changes to 3.0, unfortunately.
> > >
> > > On Wed, Aug 2, 2017 at 8:30 PM, Vladimir Ozerov <[hidden email]>
> > > 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 <[hidden email]>:
> > > >
> > > > > +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 <
> [hidden email]>
> > > > > 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 <
> > > > > > [hidden email]> 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 <
> [hidden email]
> > >:
> > > > > >>
> > > > > >>> 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.
> > > > > >>>
> > > > > >>
> > > > >
> > > > >
> > > >
> > >
> >
>

[Dmitrii Ryabov]

I mean "set readFromBackup = false" (copy-paste was bad idea).

2017-08-04 14:21 GMT+03:00 Дмитрий Рябов <[hidden email]>:

> +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 <[hidden email]>:
>
>> +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 <[hidden email]>
>> wrote:
>>
>> > We have to wait with any default changes to 3.0, unfortunately.
>> >
>> > On Wed, Aug 2, 2017 at 8:30 PM, Vladimir Ozerov <[hidden email]>
>> > 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 <[hidden email]>:
>> > >
>> > > > +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 <[hidden email]
>> >
>> > > > 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 <
>> > > > > [hidden email]> 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 <[hidden email]
>> >:
>> > > > >>
>> > > > >>> 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.
>> > > > >>>
>> > > > >>
>> > > >
>> > > >
>> > >
>> >
>>
>
>