[jboss-dev-forums] [Design of EJB 3.0] - Re: Reintroducing Asynchronous Support

[david.lloyd@jboss.com]

Does EJB 3.1 specify use of java.util.concurrent.Future?  I only ask because I've discovered a couple of problems with it for remove invocation use that I ran into when working on Remoting:

1) It is not entirely clear if .cancel() should block until it knows whether or not the cancel succeeded.  The designers clearly did not expect there to be any time lag between the invocation of the .cancel() method and the ability to determine the result.  With remote invocation one wishes to be able to cancel asynchronously; you could always return false but the docs clearly state that false means "the task could not be cancelled, typically because it has already completed normally".

2) It should not be the client's decision whether or not the server interrupts the task thread.  Nevertheless, .cancel() accepts a boolean parameter which indicates whether the task should be cancelled.  It's clear that this interface was meant to be used from code that has authority over the thread pool which is executing the task.

3) The API itself lends very little power to the end-user (no methods to await interruptibly, no way to receive failure or cancellation notifications other than catching exceptions).

4) There is no mechanism for users to register a callback which can be invoked when the operation is done.

For Remoting and XNIO I ended up creating a new future interface (within XNIO) specifically designed for I/O and remote invocation operations:

http://anonsvn.jboss.org/repos/xnio/xnio-base/trunk/api/src/main/java/org/jboss/xnio/IoFuture.java

In addition I provide abstract implementations, and a utility method to create a java.util.concurrent.Future for interfaces which require it.  Semantically, the wrapper Future will ignore the "interruptIfRunning" parameter to .cancel(), and .cancel() blocks until it is known whether the operation was successfully cancelled.

I'm not saying you should introduce an XNIO or Remoting 3 dependency - well, unless you want to :) - but I think it's safe to say that java.util.concurrent.Future isn't an acceptable mechanism for getting the result of a remote invocation.  Been there, tried that. :-)

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4184529#4184529

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4184529