EJB 3.1 Timer Service

We can inject the Timer Service using:

@Resource TimerService timerService;

Then we create the Timer and we can attach an object to it:

public void doSomething(SomeObject obj){
//...
timerService.createTimer(15*60*1000, 15*60*1000, obj);
}

The createTimer can have 4 different signatures. In the used signature, the first parameter represents the time after which the timeout should be triggered, after the method invocation. The second parameter represents the repetition period and at last, the last parameter is the object that can be attached to this timeout (it must be a Serializable object) The other signatures concerns to a single-event timer with no repetition, by receiving a long value (in miliseconds) or a Date object, and the other concerns to a timer event with repetition, but the first parameter is a Date instead of a long.

When the timer is triggered, it calls the method that is annotated with the @Timeout annotation.

@Timeout
public void methodName(Timer timer){
SomeObject obj = (SomeObject) timer.getInfo();
//...
}

The signature for the method annotated with the @Timeout annotation must have the following signature:

void <METHOD NAME>(Timer timer)

Accessing the Timer Service
Instead of injecting the Timer Service, we can retrieve it from the Session Context:

@Resource SessionContext ctx;
//...
TimerService service = ctx.getTimerService();

EJB 3.1 Interceptors

Interceptors implementation can be found where @AroundInvoke annotation is declared. The @Interceptors annotation should be used to say where it could be found the interceptor(s) implementation and to where should be applied (could be at class level or method level).
E.g
@Interceptors(Impl.class)

The method where @AroundInvoke is applied, should have the following signature:
Object <METHOD>(InvocationContext) throws Exception

The @AroundInvoke method should contain a invocationContext.proceed() invocation, in order to allow the execution chain to go on.

A default interceptor can be declared (only at the deployment descriptor file):
<assembly-descriptor>
  <interceptor-binding>
    <ejb-name>*</ejb-name>
    <interceptor-class>actionbazaar.buslogic.ActionBazaarLogger</interceptor-class>
  </interceptor-binding>
</assembly-descriptor>

The default interceptor can be disabled, at the class or method level, using the @javax.interceptor.ExcludeDefaultInterceptors
The class interceptor can be disabled, at the method level, using the @javax.interceptor.ExcludeClassInterceptors

EJB 3.1 Exceptions

SessionContext is used for Session Beans.
MessageDrivenContext is used for Message Driven Beans.

EJB 3.1 Message Driven Bean Lifecycle

MDB Lifecycle, from book "Oreilly Enterprise Javabean 3.1, 6th Edition"

EJB 3.1 Component Types

EJB 3.1 component types are:

1. Session Beans
1. Stateless Session Beans (SLSB)
2. Stateful Session Beans (SFSB)
3. Singleton Session Beans
2. Message Driven Beans (MDB's)
3. Entity Beans

• The Stateless Session Bean does not preserve conversational state.
• The Stateful Session Bean preserves conversational state and there is one instance of the session bean per client.
• The Singleton Session Bean is new to the EJB 3.1 Specification. There is only one instance of this bean type.
• The Message Driven Bean acts as an event listener. It cannot be called from the client.

For each Bean, there are lifecycle callbacks that must follow the pattern void <METHOD>().

EJB 3.1: Stateful Session Bean lifecycle

SFSB Lifecycle, from book "Oreilly Enterprise Javabean 3.1, 6th Edition"

Lifecycle events:
@PostConstruct
@PreDestroy
@PrePassivate
@PostActivate

With SessionSynchronization:

SFSB Lifecycle with SessionSynchronization, from book "Oreilly Enterprise Javabean 3.1, 6th Edition"

Programming Rules for Stateful Session Beans:

• The Stateful Session Beans maintain conversational state, so the instance variables must be Java primitives or Serializable objects.
• Since the SFSBs cannot be pooled like the SLSBs, there can be the risk of accumulating too many of them. So the client can explicitly request the removal of a bean by calling a method annotated with the @Remove annotation.

EJB 3.1: Asynchronous Methods

New to EJB 3.1, by using the @javax.ejb.Asynchronous annotation, we can achieve fire and forget invocations, useful when having long time processing methods. When the client needs to use the result, it can take use of the facilities provided by the java.util.concurrent.Future
We can use the @Asynchronous annotation on class level, so all the methods are asynchronous, or we can use the @Asynchronous annotation at the method level.

A void method can also be marked with the @Asynchronous annotation, but in this case, no exceptions will be delivered to the client.

@Asynchronous
public Future<String> doStuff(final String input){
    // do stuff and return
    return new AsyncResult<String>("myResult");
}

If the asynchronous method has a return type Future<V> and it throws an exception, the the client will get an ExecutionException when trying to retrieve the result.

Cancel a request:
The client can request a cancel on the Future<V> invocation, using
Future<V>.cancel(boolean mayInterruptIfRunning)

where the boolean parameter represents if the asynchronous method can see if the cancel was requested.
The asynchronous method can check if cancel was called by the client, by using the SessionContext.wasCancelCalled()

Retrieving the results:
final Future<String> futureTask= myEjbProxyReference.doStuff(input);
final String result= futureTask.get(10,TimeUnit.SECONDS); //should catch the TimeoutException

Please notice the if the get() method is called with no arguments, then the get() will block until the result is available. To be assure that the result is retrieved after an undefined amount of time, then the Future<V>.isDone() method should be called, to check if the asynch result processing was already finished.