EJB 3.1: Transactions and Exceptions

It confuses me a bit how transactions and exceptions get together in the EJB specification.
It always depends on the transaction type (CMT or BMT), the type of the bean (Session or MDB), and the type of the exception (Application or System Exception).

The O'Reilly Enterprise JavaBeans 3.1 book summarizes this into some tables. I hope that this can help you like it has helped me about how to think about the transactions and exceptions.

For Session and Entity Beans:

For MDBs:

Chef Programming Language

I love all these esoteric programming languages!
Chef is a programming language where your programs look like a recipe!
You can have measures like cups and tablespoons, use liquid ingredients (output as unicode characters) while dry or unspecified will output numerics, to be put on a mixing bowl (which acts like a stack) or a baking dish!

The recipe starts with a title of the dish, which is a short description of what the program does.
Next we have the ingredients, which represent the variable declarations. Next, the method, that contains the real recipe instructions, like "take ingredient from refrigerator" which means to read a numeric from an input.

Check on DangerMouse for the language specification.

Here is the "Hello World Souffle" example:


Hello World Souffle.

This recipe prints the immortal words "Hello world!", in a basically brute force way. It also makes a lot of food for one person.

Ingredients.
72 g haricot beans
101 eggs
108 g lard
111 cups oil
32 zucchinis
119 ml water
114 g red salmon
100 g dijon mustard
33 potatoes

Method.
Put potatoes into the mixing bowl. Put dijon mustard into the mixing bowl. Put lard into the mixing bowl. Put red salmon into the mixing bowl. Put oil into the mixing bowl. Put water into the mixing bowl. Put zucchinis into the mixing bowl. Put oil into the mixing bowl. Put lard into the mixing bowl. Put lard into the mixing bowl. Put eggs into the mixing bowl. Put haricot beans into the mixing bowl. Liquefy contents of the mixing bowl. Pour contents of the mixing bowl into the baking dish.

Serves 1.


EJB 3.0: Mapping between annotations and XML elements

This table is not specific for EJB 3.1, it misses some new stuff like the Singleton annotation, but it is pretty cool to have an idea of the mapping between XML elements and annotations.

Source: EJB 3 in Action, First Edition, Manning

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.