Quick Tip: Exception Handling in Message Driven Beans

Let’s do a quick review of exception handling with regards to Message Driven Beans.

The entry point into a MDB is the overridden onMessage method. It does not provide any scope for throwing checked exceptions and as a result, you will need to propagate unchecked exceptions (subclass of java.lang.RuntimeException) from your code if you want to handle error scenarios.

Types of exceptions

There are two categories of exceptions defined by the EJB specification and the container differentiates one from the other based on well stated semantics (again, in the EJB specification).

Application Exception

If you throw a checked exception (not possible for MDB but other EJBs can use this) which is not a java.rmi.RemoteException or it’s subclass, OR a RuntimeException (unchecked) which is annotated with @javax.ejb.ApplicationException, the container treats this as an Application Exception. As a result, it rolls back transaction if specified by the@javax.ejb.ApplicationException rollback attribute and retains the MDB instance for reuse – this is extremely important to note.

@ApplicationException(rollback = true)
public class InvalidCustomerIDException extends RuntimeException {
    public InvalidCustomerIDException(){
        super();
    }
}

If you throw a java.rmi.RemoteException (a checked exception) or it’s subclass, OR a RuntimeException (unchecked) which is not annotated with@javax.ejb.ApplicationException, the container treats it as a System Exception. As a result, it executes certain operations like transaction rollback and discards the MDB instance (this is critical).

public class SystemExceptionExample extends Exception {
    public SystemExceptionExample(){
        super();
    }
}

It is important to take into account, the discarding of the MDB instance. In case of System Exceptions, the container always discards the instance – so make sure that you are using these exceptions for their intended reason. In case you are using Application Exceptions and they are unchecked ones (they have to be in case of MDBs), make sure you annotate them with @javax.ejb.ApplicationException – this will ensure that the MDB instance itself is not discarded.

Under heavy loads, you would want to have as many MDBs in the pool as possible and you would want to avoid MDB instances being moved out of service. Sensible exception handling can help you realize this goal. It’as simple as annotating your exception class with@javax.ejb.ApplicationException and leaving the rest to the container :-)

References

The EJB (3.2) specification is a 465 page PDF which might look intimidating at the outset, but it’s a great resource nonetheless and not that hard to grasp. In case you want to understand Exception Handling semantics in further detail, please do check out Chapter 9which is dedicated to this topic

Cheers!