Java Reference
In-Depth Information
3.5.2. When to use asynchronous session beans
Asynchronous session beans should be used only under two circumstances:
• You have a long-running operation that you want to start and then continue
something else, regardless of what happens with this operation.
• You have a long-running operation for which you want to start and then check back
later to see what the result is after doing something. You may also want to cancel
this operation.
Prior to EJB 3.1, the only way to do either of these was to multithread your client. Because
the container controlled concurrency, there was no way to notify a bean that a long-running
operation should be cancelled. Remember, the container controls concurrency, so each
method was synchronized on the bean, meaning that only one thread could invoke a meth-
od at a time. EJB 3.1 is thus a point release with additional major functionality.
Asynchronous session beans are intended to be lightweight, so they don't provide any re-
liability guarantees. This means that if a container crashes while an asynchronous method
is getting executed, the method won't recover. Asynchronous beans are also not loosely
coupled, which means that a client holds a direct reference to the asynchronously invoked
session bean. If you require reliability and loose coupling and not just asynchronous pro-
cessing, you should consider message-driven beans.
3.5.3. ProcessOrder bean example
To put asynchronous methods in context, let's return to the ActionBazaar application. There
are two order-processing tasks that are candidates for parallelization: sending out the con-
firmation email and debiting the credit card. Sending out the email is a fire-and-forget task;
therefore, there's no return value. Processing the credit card, on the other hand, may take a
while, but you need to know that the card was debited before continuing. If there's an error,
you want to stop the process and immediately notify the bidder that the transaction couldn't
be completed. Both of these asynchronous tasks started by the
ProcessOrder
stateless
session bean are shown in the next listing.
