Let’s do a quick review of exceptional 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();
}
}
System Exception
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();
}
}
What about the critical part ??
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 9 which is dedicated to this topic
Cheers!
| Reference: | Quick tip: Exception handling in Message Driven Beans from our JCG partner Abhishek Gupta at the Object Oriented.. blog. |
