EJB 3.1 asynchronous methods

The Enterprise JavaBeans™ (EJB) 3.1 specification includes functionality that application developers can use to configure EJB asynchronous methods, which are run on a separate thread from the caller thread.

This mechanism decouples the client invocation request from the actual method execution. The client thread can continue doing other work while the EJB method is run on a separate thread, as directed by the EJB container.

Later, the client might want to examine the result of the asynchronous method execution, which is sometimes referred to as fire and return. In this case, the EJB container returns to the client an object that implements the java.util.concurrent.Future<V> interface. The client can use this object to check status, results, or exceptions from the asynchronous method invocation. Alternatively, asynchronous methods might not return any results, which is sometimes referred to as fire and forget.

For more details, see information about how to use EJB asynchronous methods in your application.

Here are some example usage scenarios for EJB asynchronous methods:

• An application has multiple, independent, pieces of work that all must be executed to produce a final result. For example, suppose that a travel reservation consists of three parts:
  1. Making a plane reservation.
  2. Making a rental car reservation.
  3. Making a hotel reservation.
  In this example, a client can use EJB asynchronous methods to process the reservation requests in parallel. After all three reservation methods run, the client aggregates the results into a complete travel reservation.
• An application has multiple, independent, pieces of work that it must run, and the application is not concerned about the results of this work. For example, suppose that a retailer has four branch stores, and the home office wants to print a sales report from each store when the business day ends. The application developer can use EJB asynchronous methods as a batch processing mechanism. Multiple EJB method calls can be used to send a batch of get sales report requests, one to each branch store.

  In this example, presumably the application does not need to check for results from these method calls. Perhaps this is handled by the home office employee who picks up the sales reports from a printer the next morning. Suppose that one of the branch stores failed to provide the requested report. The person collecting the reports can decide if that was expected, for example, the branch store was closed for renovations, or if the get sales report request must be reissued to that branch store.