Alex.
Of course, some distributed operations will involve some kind of asynchrony
even in synchronous mode. My point is that we should not blindly do things
like that:
V get(K key) {
return getAsync(key),get();
}
Instead, get() has it's own path, getAsync() another path. But of course
they could share some common places. E.g. I remember we already fixed some
cache operations in this regard when users hit async semaphore limit when
calling synchronous gets.
Another point is that async instances may possibly accept user-provided
Executor.
Vladimir,
On Thu, Jul 21, 2016 at 11:04 AM, Semyon Boikov <sboi...@gridgain.com>
wrote:
> Another issue which usually confuses users is Ignite 'implementation
> details' of asynchronous execution: it operation is local it can be
> executed from calling thread (for example, if 'async put' is executed in
> atomic cache from primary node then cache store will be updated from
> calling thread). Does it make sense to fix this as well?
>
>
> On Thu, Jul 21, 2016 at 10:55 AM, Yakov Zhdanov <yzhda...@apache.org>
> wrote:
>
> > Agree with Alex. Vova, please go on with issues taking Alex's comments
> into
> > consideration.
> >
> > Thanks!
> >
> > --Yakov
> >
> > 2016-07-21 10:43 GMT+03:00 Alexey Goncharuk <alexey.goncha...@gmail.com
> >:
> >
> > > Big +1 on this in general.
> > >
> > > I would also relax our guarantees on operations submitted from the same
> > > thread. Currently we guarantee that sequential invocations of async
> > > operations happen in the same order. I think that if a user wants such
> > > guarantees, he must define these dependencies explicitly by calling
> > chain()
> > > on returning futures.
> > >
> > > This change will significantly improve cache operations performance in
> > > async mode.
> > >
> > > 3) Sync operations normally* should not* be implemented through async.
> > This
> > > > is a long story - if we delegate to async, then we have to bother
> with
> > > > additional threads, associated back-pressure control and all that
> crap.
> > > > Sync call must be sync unless there is a very strong reason to go
> > through
> > > > async path.
> > > >
> > > Not sure about this, though. In most cases a cache operation implies
> > > request/response over the network, so I think we should have explicit
> > > synchronous counterparts only for methods that are guaranteed to be
> > local.
> > >
> >
>
