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