Asynchronous API thoughts & questions

[Jim Bethancourt]

I listened to Roger Brinkley's interview with Marina Vatkina on the EJB 3.2 proposed specification (https://blogs.oracle.com/javaspotlight/entry/java_spotlight_episode_91_marina), and she mentioned that EJB asynchronous method invocations and/or classes can be marked with an @Asynchronous annotation and the call will be handled in an asynchronous fashion.  I found that section 4.5 of the EJB 3.2 spec (http://jcp.org/en/jsr/detail?id=345) describes the use and functionality of this annotation and mentions the concrete AsyncResult container class , and got to thinking maybe the same approach might make sense here too.

I remember we had a fairly vigorous discussion around the topic of an asynchronous API and how to design fluent synchronous and asynchronous interfaces that would be easy to use.  Perhaps we could consider taking the same approach of using an annotation for the DataGrid API and check if the calling method / class is annotated with a @javax.datagrid.Asynchronous annotation in the implementation instead of having separate synchronous / asynchronous APIs in the specification, and have the caller return a Future if their method is an asynchronous one.  Perhaps the @javax.ejb.Asynchronous annotation could trigger the DataGrid's asynchronous call stack to be used as well (at least in the RI)?  Thoughts?

The EJB 3.2 specification also addresses transaction propagation in section 4.5.2 and exception behavior in 4.5.5 in an asynchronous context, both of which might want to be considered in this specification as well.

Cheers,

Jim

[Manik Surtani]

Hmm.  But this would affect the return types in the method signatures, right?

--
You received this message because you are subscribed to the Google Groups "JSR 347 discussions" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jsr347+un...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Joseph Ottinger]

Yeah, @Asynchronous methods have to return a Future<> or are void. 

Since we do have control over the interfaces, I don't think we need the annotation - although I suppose we could play with signatures like this:

Container<K,V> {

  <T> T get(K);

}

With this structure, T would implement either V or Future<V>, and get() would determine what to do based on the actual type passed in.

That's not to say that this sounds wise, or doable, or whatever - just trying to think through the applications. I still think having two interfaces (Container<K, V> and AsyncContainer<K, V> extends Container<K, V>) makes the most sense - or if I didn't think it before, I do now. :)

--
Joseph B. Ottinger
http://enigmastation.com

Memento mori.

[Jim Bethancourt]

I'm thinking it wouldn't affect method signatures, at least not in the DataGrid API.  I'm thinking the return type would be different in the caller's API return type (they would be the one returning the Future<V>), but the calls made to the DataGrid API would all happen in the asynchronous context of the method call and would still return V.

I guess I'm trying to come from the perspective of trying to ask "What's the simplest thing that could possibly work (for the end user)?".

Thanks,

Jim