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 >
