I mean "set readFromBackup = false" (copy-paste was bad idea). 2017-08-04 14:21 GMT+03:00 Дмитрий Рябов <somefire...@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 <avinogra...@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 <dsetrak...@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 <voze...@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 <dma...@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 <voze...@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.goncha...@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 <voze...@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. >> > > > >>> >> > > > >> >> > > > >> > > > >> > > >> > >> > >
