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

[ALRubinger]

"david.lloyd at jboss.com" wrote : Does EJB 3.1 specify use of java.util.concurrent.Future?

Yes.

"EJB 3.1 Core Specification 4.5.2" wrote : The client return type of an asynchronous method is either void or java.util.concurrent.Future, where V is the result value type.

"david.lloyd at jboss.com" wrote : 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...

Clearly I'd like to take advantage of your experience here, but not at the expense of confusing users with more nonstandard APIs.  So perhaps I can take a hybrid approach.

"david.lloyd at jboss.com" wrote : 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".

Though not explicitly stated, to fulfill the JavaDoc's requirements of j.u.c.Future, we'd have to block until we knew whether the operation would be cancelled.

In the case of EJB, a call to "cancel" is a request by the client.  The bean must be written to support cancellation, and "mayInterruptIfRunning" would have to be ignored as that context is not available to the bean provider to check.

"EJB 3.1 Core Spec, 3.5.2.2" wrote : A client can request that an asynchronous invocation be cancelled by calling the Future.cancel(boolean mayInterruptIfRunning) method. A Bean Developer can check whether the client has requested cancellation by calling the SessionContext.isCancelled() method within the context of the asynchronous method.

Now, if the bean provider chooses to honor the request to cancel, there's a missing mechanism to let the client to know whether the request was fulfilled.  So what should be the proper return value of "cancel()"?

I'll pose this question to the JSR318 EG.

"david.lloyd at jboss.com" wrote : 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.

>From the spec above, this flag is lost and not available in SessionContext anyway.

"david.lloyd at jboss.com" wrote : 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.

True story.  The implementation I'm looking to replace/simplify also provides blocking to "get" via the Oswego concurrent utils.  And only the XNIO impl provides for callbacks.

At first glance I'd approach this by using a XNIO Future impl under the hood, and wrapping w/ j.u.c.Future to return to the client.  This would also pave the way to provide for more than one async interface to the client, who could choose his view (XNIO, j.u.c, etc).  I'm weary of drawing in another dependency unless it's already brought into AS somewhere?

Then again, eventually we're gonna need Remoting 3 which depends on XNIO, so worst case is we'd be tacking on this library prematurely...

S,
ALR

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

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