It is a matter of taste. In .NET we have "Async" methods near synchronous
methods because it is common practice in .NET world:
V Get(K key);
Task<V> GetAsync(K key);
For Java we can go the same way, or introduce separate interface. It will
not be identical to synchronous, because it will have different return
types and probably will contain only those methods which support async
execution.
Personally I like .NET approach. It is simple and straightforward. User do
not have to bother about whether current instance is sync or async (like
now), and will not have to perform additional steps like
*IgniteCache.withAsync().get()*. Do you want to call GET asynchronously? No
problem, *IgniteCache.getAsync()*. Simple, expressive, straightforward.
The drawback is that our interfaces will become "heavier". But it is 2016
year, we all have IDEs. I do not see any problems if we will have 62 + 36 =
98 methods instead of current 62 on cache API.
Vladimir.
On Thu, Jul 21, 2016 at 12:21 PM, Dmitriy Setrakyan <dsetrak...@apache.org>
wrote:
> Do I understand correctly that the community is proposing to have 2
> identical interfaces, one for sync operations and another for async
> operations?
>
> On Thu, Jul 21, 2016 at 12:15 PM, Sergi Vladykin <sergi.vlady...@gmail.com
> >
> wrote:
>
> > +1
> >
> > Finally it is time to drop this "cool feature" from Ignite!
> >
> > Sergi
> >
> > On Thu, Jul 21, 2016 at 11:13 AM, Vladimir Ozerov <voze...@gridgain.com>
> > wrote:
> >
> > > 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.
> > > > > >
> > > > >
> > > >
> > >
> >
>
