>It still seems that outdated reads will be *more* outdated with async mode. >Also, is there a guarantee that a near-cache update will happen at all, if >you introduce the async mode?
We have the same guarantees for continuous queries - updates are sent to listener and no ack is required on grid level protocol (communication guaranteed delivery is used). If near node receives messages and process them, then the update should happen, if it does not receive messages it should be thrown out of topology as message queue to it grows (slow client limit) I do not want to operate "more outdated" or "less outdated" definitions. To me both of them are pretty much the same :) Want up to date reads - read from primary or in TX, all other options may be "outdated". > Is this going to be the default flag? Well, I don't want to take decision at the moment, but having DHT_SYNC seems very good option to me. PRIMARY_SYNC may stay default. All I want is to have opportunity to update near readers in async way. >Are you really suggesting that TX is committed without a guarantee that >near cache update happened? Do not see any issue here. You can ensure consistency and reread the value in TX. Or you can enforce this by choosing FULL_SYNC for this update. Btw, is there any way to override configured writeSync mode? Seems pretty nice to have IgniteCache.withWriteSynchronizationMode(Mode m) >This would be a great optimization. It sounds like it could be done >independently from sync or async updates of near caches, no? I think so >I still don't see it. It is still possible for a near node to be alive, but >unresponsive. In this case, there is a possibility that a near cache will >never be updated, even though the transaction has already been committed. >This just does not seem kosher to me. See above example for continuous queries and slow client queue limit. Thanks! --Yakov 2017-02-04 12:12 GMT+07:00 Dmitriy Setrakyan <dsetrak...@apache.org>: > Hm... interesting. My questions are inline. > > On Mon, Jan 30, 2017 at 3:29 PM, Yakov Zhdanov <yzhda...@apache.org> > wrote: > > > Guys, > > > > Currently when we do cache updates in FULL_SYNC mode we update near > readers > > (near cache entries) synchronously. This is quite big drawback in > design, I > > think. I get each near reader update at cost of 1 extra backup update. I > > think everyone understands that partitioned cache easily turns to > > replicated once near readers number increases. In TX cache cost of such > > updates doubles. > > > > I do not see any benefit on updating near entries in sync way. Outdated > > reads can still be possible if I don't read from primary or in TX > context. > > > > It still seems that outdated reads will be *more* outdated with async mode. > Also, is there a guarantee that a near-cache update will happen at all, if > you introduce the async mode? > > > > > So, what I suggest: > > 1. introduce flag for cahce - withSyncNearUpdates() or extra > > CacheWriteSynchronizationMode.DHT_SYNC and make it default mode. > > > > Is this going to be the default flag? > > > > 2. Near entries are updated in async way > > 2.1 in atomic mode together with backup updates > > 2.2 in TX mode after tx is committed on primary > > > Are you really suggesting that TX is committed without a guarantee that > near cache update happened? > > I would also suggest to exclude near readers from lock acquisition/release > > steps. Only force updates. Updates order will be ensured by single > primary > > node and > > per-partition striping. > > > > This would be a great optimization. It sounds like it could be done > independently from sync or async updates of near caches, no? > > > > 3. Near readers do not respond to primary. Once primary fails near > readers > > get invalidated, if primary is alive then communication recovery ensures > > that message will be delivered to near. > > > > I still don't see it. It is still possible for a near node to be alive, but > unresponsive. In this case, there is a possibility that a near cache will > never be updated, even though the transaction has already been committed. > This just does not seem kosher to me. > > > > > > Please share your thoughts. > > > > --Yakov > > >
