Dima, I do not like JSR 107 v1.1 approach. First, it is not user friendly. Second, it is prone to deadlock/starvation problems we are currently discussing in another thread because these "Collectors" are continuations essentially.
On Tue, Oct 13, 2015 at 12:42 AM, Dmitriy Setrakyan <dsetrak...@apache.org> wrote: > I just took a look at JSR 107, and looks like they are taking a different > (in my view not as elegant) route: > > https://github.com/jsr107/jsr107spec/blob/async/src/main/java/javax/cache/Cache.java > > Any thoughts on this? > > D. > > On Mon, Oct 12, 2015 at 11:11 AM, Vladimir Ozerov <voze...@gridgain.com> > wrote: > > > Well, if we asume that the most common usage will be > > IgniteCache.async().doSomething(), then yes - backwards transformation is > > not necessary. > > > > All in all this approach seems to be the most clean among other > suggested. > > > > On Mon, Oct 12, 2015 at 8:38 PM, Sergi Vladykin < > sergi.vlady...@gmail.com> > > wrote: > > > > > Dmitriy, > > > > > > I mostly agree with your points except naming and hierarchy: > > > > > > 1. I don't like CacheAsync, it is ugly. > > > > > > 2. If IgniteCache extends AsyncCache then we can't use the same names > for > > > methods, we will be forced to use *blaAsync(...)* format > > > which is ugly for me as well. Also this will pollute sync API with > async > > > one, while we are trying to avoid that. > > > > > > Sergi > > > > > > 2015-10-12 20:28 GMT+03:00 Dmitriy Setrakyan <dsetrak...@apache.org>: > > > > > > > On Mon, Oct 12, 2015 at 10:15 AM, Vladimir Ozerov < > > voze...@gridgain.com> > > > > wrote: > > > > > > > > > > > > > The problem with this approach is that not all methods are async. > > E.g. > > > > > name(), lock(K), iterator(), etc.. So you should either mix sync > and > > > > async > > > > > methods in AsyncCache still, or expose only async methods. > > > > > > > > > > > > I think AsyncCache, or rather CacheAsync, should expose only async > > > methods. > > > > Moreover, should IgniteCache simply extend CacheAsync API? > > > > > > > > > > > > > In the latter case we will require backwards > > > > > transformation: IgniteCache AsyncCache.sync(). > > > > > > > > > > > > > Not sure this is needed. > > > > > > > > > > > > > Consistency between platforms should have minimal priority. .Net > and > > > Java > > > > > are very different. For example we cannot even have "V Get(K)" > method > > > in > > > > > .Net cache. Instead we have "V TryGet(K, out bool)" because .Net > > > supports > > > > > structs and have full generics support and naive Java approach > simply > > > > > doesn't work here. Base concepts must be the same across platforms, > > but > > > > > methods signatures and grouping will be different. > > > > > > > > > > > > > I disagree here. I think consistency matters. Moreover, based on the > > > > previous .NET examples you have provided, I do not see much > difference > > > > between .NET and Java, other than different syntax. I think the same > > > > CacheAsync design can be applied to both. > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Mon, Oct 12, 2015 at 7:53 PM, Sergi Vladykin < > > > > sergi.vlady...@gmail.com> > > > > > wrote: > > > > > > > > > > > In my view we should not pollute sync APIs with all async > methods, > > > > > > definitely we have to separate them > > > > > > for better UX. > > > > > > > > > > > > Currently on Java we have IgniteAsyncSupport with method > > withAsync() > > > > > which > > > > > > returns the same sync API > > > > > > but that API works in broken manner. Instead it should look like > > the > > > > > > following IMO > > > > > > > > > > > > interface AsyncSupport<X> { > > > > > > X async(); > > > > > > } > > > > > > > > > > > > Where X will be an interface with respective async API. For > > example > > > > for > > > > > > IngneCache we will have AsyncCache > > > > > > with all the respective async variants of all methods. Like this > > > > > > > > > > > > interface IgniteCache<K,V> extends AsyncSupport<AsyncCache<K,V>> > { > > > > > > V get(K key); > > > > > > } > > > > > > > > > > > > > > > > > > interface AsyncCache<K,V> { > > > > > > IgniteFuture<V> get(K key); > > > > > > } > > > > > > > > > > > > From implementation standpoint both interfaces can be implemented > > by > > > > the > > > > > > same class but for user API > > > > > > they will be conveniently separated. Implementation of every sync > > > > method > > > > > is > > > > > > trivial if we have > > > > > > async counterpart: just call get() on received future. > > > > > > > > > > > > From documentation point of view we just have to write on each > > method > > > > > that > > > > > > it is a async variant of some > > > > > > method on main API like following: > > > > > > > > > > > > /** > > > > > > * Asynchronous variant of method {@link > > > IgniteCache#get(Object)}. > > > > > > */ > > > > > > > > > > > > This way we will not need to maintain the same docs for all sync > > and > > > > > async > > > > > > methods. > > > > > > > > > > > > Sorry, I'm not an expert in .Net but I believe this approach will > > fit > > > > > .Net > > > > > > as well, so it can be consistent across platforms. > > > > > > > > > > > > Sergi > > > > > > > > > > > > > > > > > > > > > > > > 2015-10-12 19:10 GMT+03:00 Dmitriy Setrakyan < > > dsetrak...@apache.org > > > >: > > > > > > > > > > > > > Do I understand correctly that you are suggesting adding > > > "Async(..)" > > > > > > > counterparts for all the synchronous methods? > > > > > > > > > > > > > > Are there any objections about this? If we do it in .NET, then > we > > > > might > > > > > > as > > > > > > > well do it in Java, because in my view the same reasoning can > be > > > made > > > > > for > > > > > > > Java. This will cause significant proliferation of Async > methods. > > > For > > > > > > > example just on IgniteCache API, we will have to add about 40 > > > Async() > > > > > > > methods. > > > > > > > > > > > > > > D. > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Mon, Oct 12, 2015 at 3:45 AM, Vladimir Ozerov < > > > > voze...@gridgain.com > > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > No. "await" is actually return from the method immediately. > Let > > > me > > > > > show > > > > > > > it > > > > > > > > again: > > > > > > > > > > > > > > > > async Task<int> GetAndMultiply() { > > > > > > > > Task<int> res = cache.GetAsync(1); > > > > > > > > > > > > > > > > await res; > > > > > > > > > > > > > > > > return res.Result * res.Result; > > > > > > > > } > > > > > > > > > > > > > > > > maps to the following pseudo-code in Java: > > > > > > > > > > > > > > > > Future<Integer> getAndMultiply() { > > > > > > > > Future<Integer> res = cache.getAsync(1); > > > > > > > > > > > > > > > > return res.chain((f) => { > > > > > > > > return f.get() * f.get(); > > > > > > > > }); > > > > > > > > } > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Mon, Oct 12, 2015 at 1:36 PM, Yakov Zhdanov < > > > > yzhda...@apache.org> > > > > > > > > wrote: > > > > > > > > > > > > > > > > > Is current thread blocked until "await" instruction is > > > completed > > > > in > > > > > > > > > parallel thread? > > > > > > > > > > > > > > > > > > --Yakov > > > > > > > > > > > > > > > > > > 2015-10-12 10:41 GMT+03:00 Vladimir Ozerov < > > > voze...@gridgain.com > > > > >: > > > > > > > > > > > > > > > > > > > Example with Get() operation: > > > > > > > > > > > > > > > > > > > > async Task<int> GetAndMultiply() { > > > > > > > > > > // This line is executed in current thread. > > > > > > > > > > Task<int> res = cache.GetAsync(1); > > > > > > > > > > > > > > > > > > > > await res; > > > > > > > > > > > > > > > > > > > > // This code is executed in another thread when res > is > > > > ready. > > > > > > > > > > int mul = res.Result * res.Result; > > > > > > > > > > > > > > > > > > > > return mul; > > > > > > > > > > } > > > > > > > > > > > > > > > > > > > > On Mon, Oct 12, 2015 at 10:12 AM, Dmitriy Setrakyan < > > > > > > > > > dsetrak...@apache.org > > > > > > > > > > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > On Sun, Oct 11, 2015 at 3:42 AM, Vladimir Ozerov < > > > > > > > > voze...@gridgain.com > > > > > > > > > > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > Guys, let's try keeping this topic focused on .Net > > > please, > > > > > > > because > > > > > > > > > the > > > > > > > > > > > > product is not released yet and we can create any API > > we > > > > > like. > > > > > > > > > > > > > > > > > > > > > > > > Dima, answering your question about async/await - > this > > is > > > > > > > actually > > > > > > > > > > native > > > > > > > > > > > > continuation support in .Net. Consider the following > > .Net > > > > > > method: > > > > > > > > > > > > > > > > > > > > > > > > async void PutAndPrint() { > > > > > > > > > > > > await cache.PutAsync(1, 1); > > > > > > > > > > > > > > > > > > > > > > > > Console.WriteLine("Put value to cache."); > > > > > > > > > > > > } > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > And what if the method putAsync would return a value. > How > > > > would > > > > > > > this > > > > > > > > > code > > > > > > > > > > > change? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
