ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dmitriy Setrakyan <dsetrak...@apache.org>
Subject Re: Ignite-2.0 - Make near readers update async by default
Date Sat, 04 Feb 2017 05:12:34 GMT
Hm... interesting. My questions are inline.

On Mon, Jan 30, 2017 at 3:29 PM, Yakov Zhdanov <yzhdanov@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

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message