ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vladimir Ozerov <voze...@gridgain.com>
Subject Re: Ignite-2.0 - Make near readers update async by default
Date Mon, 06 Feb 2017 08:20:04 GMT
Yakov,

I think forcing reads in TX or from primary is not what users expect by
default. So i would have this mode disabled by default.

On Mon, Feb 6, 2017 at 10:40 AM, Yakov Zhdanov <yzhdanov@apache.org> wrote:

> >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 <dsetrakyan@apache.org>:
>
> > 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
> > >
> >
>

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