> 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
What really matters is consistency with the rest of .NET platform. There are clear design guidelines: https://msdn.microsoft.com/en-us/library/hh873175(v=vs.110).aspx These guidelines are followed throughout standard APIs. Everyone is used to them. Really, there is no need to invent anything. It won't be better. "When in Rome, do as the Romans do". Thanks, On Tue, Oct 13, 2015 at 8:56 AM, Vladimir Ozerov <voze...@gridgain.com> wrote: > 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? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- -- Pavel Tupitsyn GridGain Systems, Inc. www.gridgain.com
