> Do we have a choice here? We will have to implement JSR107 anyway. Let's > just make sure that whatever approach we come up with does not contradict > JSR107 functionality.
As I understand from JSR107 mailing list, nobodody really understand what the next version will be about. For now they are focused on maintenance release and async operations are not planned here. Some event is planned at the end of October at JavaOne which should boost further discussions. As for async methods you mentioned, they were submitted recently into a separate branch by Greg Luck and it is neither design draft, neither proposed solution. Just some code without any official status. On Tue, Oct 13, 2015 at 12:14 PM, Dmitriy Setrakyan <[email protected]> wrote: > On Mon, Oct 12, 2015 at 10:56 PM, Vladimir Ozerov <[email protected]> > 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. > > > > Do we have a choice here? We will have to implement JSR107 anyway. Let's > just make sure that whatever approach we come up with does not contradict > JSR107 functionality. > > > > > > On Tue, Oct 13, 2015 at 12:42 AM, Dmitriy Setrakyan < > [email protected] > > > > > 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 < > [email protected]> > > > 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 < > > > [email protected]> > > > > 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 < > [email protected] > > >: > > > > > > > > > > > On Mon, Oct 12, 2015 at 10:15 AM, Vladimir Ozerov < > > > > [email protected]> > > > > > > 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 < > > > > > > [email protected]> > > > > > > > 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 < > > > > [email protected] > > > > > >: > > > > > > > > > > > > > > > > > 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 < > > > > > > [email protected] > > > > > > > > > > > > > > > > > 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 < > > > > > > [email protected]> > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > Is current thread blocked until "await" instruction is > > > > > completed > > > > > > in > > > > > > > > > > > parallel thread? > > > > > > > > > > > > > > > > > > > > > > --Yakov > > > > > > > > > > > > > > > > > > > > > > 2015-10-12 10:41 GMT+03:00 Vladimir Ozerov < > > > > > [email protected] > > > > > > >: > > > > > > > > > > > > > > > > > > > > > > > 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 < > > > > > > > > > > > [email protected] > > > > > > > > > > > > > > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > On Sun, Oct 11, 2015 at 3:42 AM, Vladimir Ozerov < > > > > > > > > > > [email protected] > > > > > > > > > > > > > > > > > > > > > > > > > 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? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
