EJB 3.1 – Asynchronous Session Beans

The Session Bean Component Contract of the Enterprise JavaBeans 3.1 Specification (JSR 318 Proposed Final Draft) introduces the possibility of exposing methods of session beans with asynchronous semantics.

What does that mean?
For asynchronous invocations, control returns to the client before the container dispatches the invocation to a bean instance.
When a client invokes an asynchronous method, the container returns control to the client immediately and continues processing the invocation on a separate thread.

How to expose session bean’s methods asynchronously
Annotation: @Asynchronous

This annotation can be applied to

  • a business method of a bean class
  • a method of a Local/Remote business interface
  • the class level of a bean class (or super class)
  • the class level of a particular Local/Remote business interface (or super interface)

Application to a class level causes that all methods declared on that class or interface are asynchronous.

Alternatively, asynchronous methods can be designated via the deployment descriptor.

What does an asynchronous method look like?
The return type of an asynchronous method is either void or java.util.concurrent.Future<V>, where V is the result value type.

Return Type Behaviour
void must not declare any application exceptions
Future<V>
  • is permitted to declare application exceptions
  • used to make the return value of an asynchronous method invocation available to the client
  • javax.ejb.AsyncResult<V> is a concrete Future implementation that is provided by the container. Its constructor takes the result value as a parameter.

The Client View
When invoking an asynchronous method the client should expect to receive a system exception (javax.ejb.EJBException).
The system exception will be thrown by the container if it has problems to allocate the internal resources required to support the asynchronous method. The client may retry the asynchronous method invocation at a later time.

Any application exception resulting from the method execution will be available via the Future<V> object.

Interpretation of the Future<V> object

Method Behaviour
Future.cancel(...)
  • The container will attempt to cancel the associated asynchronous invocation
  • The cancellation of the asynchronous method can only be attempted by the container if that invocation has not already been dispatched (Attention! There is no guarantee that the invocation can be cancelled!)
  • Must return true, if the invocation is successfully cancelled
  • Must return false, if invocation cannot be cancelled
Future.get
  • Used by the client to retrieve the result value or resulting exception from the associated asynchronous invocation
  • Important: If a call to get successfully returns a resul value or throws an ExecutionException, all subsequent calls on the same Future object must result in the same behaviour.

Timeouts
An EJB Container Provider is permitted to define a timeout value that governs the maximum amount of time the container maintains result values for completed asynchronous invocations. However, the configuration of this timeout is vendor-specific.

Transactions
From the session bean’s view there is never a transaction context flowing in from the client to asynchronously invoked methods.
Example: The semantics of the REQUIRED transaction attribute on an asynchronous method are exactly the same as REQUIRES_NEW.