WAS v8.5 > Develop applications > Develop EJB applications > Develop session beans > Configure EJB 3.1 session bean methods to be asynchronous > Develop client code that calls EJB asynchronous methodsClient programming model for EJB asynchronous methods
As documented in the EJB 3.1 specification, we can invoke EJB asynchronous methods through the following interface types: local business, remote business, or no-interface view. Invocations through an EJB 2.1 client view, or a web services view, are not allowed.
The interface specification for an EJB asynchronous method must have a return type of void, or of type java.util.concurrent.Future <V>. No other return types are supported on the interface. As documented in the EJB 3.1 specification, the bean implementation method must have the same return type.
When the application does not need to examine the result of an EJB asynchronous method call, use an interface signature with a return type of void. Conversely, when the application needs to examine the result of an EJB asynchronous method call, use an interface with a return type of Future<V>.
In addition to considering whether results are examined, clients must be prepared to handle exceptions. As documented in the EJB 3.1 specification, the client receives an exception if the container is unable to allocate the internal resources required to schedule the asynchronous method for execution. In this case, the client can assume the asynchronous method does not run. Also, exceptions can occur while the asynchronous method is running on the non-client thread.
When an asynchronous method has a return type of void, the client has no mechanism to retrieve exception information. The EJB container logs an informational message in this case. However, for asynchronous methods that have a return type of Future<V>, the EJB container saves exception information in the Future<V> object. In this case, the get methods associated with the Future<V> object produce the exception, ExecutionException. The client must invoke the getCause method on the ExecutionException to retrieve details about the exception.Clients must know the get methods on the Future<V> object block the client thread if the asynchronous method has not finished running when the get method is called. If clients do not want this behavior, they can poll the Future<V> object to determine when the asynchronous method is finished by periodically calling the isDone method.
Finally, clients can use the Future<V> object to cancel an asynchronous method call. If you attempt to cancel an asynchronous method call while it is waiting to run, then it does not run, and other interactions with the Future<V> object reflect the cancellation. Otherwise, if you attempt to cancel an asynchronous method after it has started running, then it continues to run, but the bean method can still determine the client attempted to cancel the call and respond with an application-specific return value or exception.
Another alternative is for the client to use the get method, which includes a timeout parameter. This get method only waits for results during the specified timeout period. The get method returns to the client as soon as the method has finished running, or when the timeout expires, even if the method has not finished running.
Nested asynchronous calls are supported; an asynchronous method call can be made from within an asynchronous method.
When nesting asynchronous method calls, take into consideration the work manager settings to allow enough resources (maximum number of threads and work request queue size). For more information, read about the EJB container work manager for asynchronous methods.
Read about Developing client code that calls EJB asynchronous methods.
Related concepts:
EJB 3.1 asynchronous methods
EJB container work manager for asynchronous methods
Bean implementation programming model for EJB asynchronous methods
Related
Configure EJB 3.1 session bean methods to be asynchronous