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