Many of you have been developing EJB applications since the 1.0 version of the specification. In the EJB 1.1 specification the approach toward EJB exception handling has changed slightly regarding the exceptions and transaction management responsibilities between bean providers and container vendors.
Those of you who made the conversion from 1.0 to 1.1 may not have enjoyed this "tightening" of the spec. Exceptions are thrown at many different levels in large applications; each exception has a specific meaning and is handled differently by your application. To change how your application handles exceptions can be a daunting task. For instance, you have to make sense of the container's responsibilities versus yours as a bean provider. Also, you must understand how to use new exceptions correctly and which exceptions have been deprecated from certain usage.
This month I'll talk about the main types of exceptions you'll encounter when developing EJBs to the 1.1 specification. I'll discuss the differences between exception and transaction management in the 1.0 and 1.1 EJB specifications and describe each type of exception, categorizing commonly thrown exceptions for you. My intention is to shed some light on exception handling in 1.1-compliant EJBs to either smooth your conversion or ease your new EJB development effort.
EJB Exceptions in 1.0
The 1.0 specification divides exceptions and their effects on the current transaction based on who initiated the transaction and how exceptions are handled in the scope of the transaction. It can initiate a transaction three ways: client-managed, bean-managed and container-managed. Depending on your choice for transaction management, your recourse on a failed action is extremely different. Let's examine how the 1.0 specification handled transactions and exceptions to better understand the differences between exception handling in a 1.0- and 1.1-compliant container.
Client-Managed Transactions in 1.0
Client-managed transactions are transactions initiated on the client that generally span multiple calls to one or more EJBs. Because the client manages the scope of the transaction, it can assess exceptions thrown to it and determine whether to retry the business function or simply roll back the transaction, essentially calling it quits! The ability to retry calls to your EJBs without the transaction rolling back is a great feature, since remote method invocations are inherently less reliable than local calls. In a clustered environment we may be able to retry the same EJB on another server without disrupting the execution of the transaction.
Bean-Managed Transactions in 1.0
Exceptions thrown in entity or stateless session beans that manage their own transactions automatically signal the container to roll back the transaction. The container doesn't distinguish exception types; it simply marks the transaction for immediate rollback. Stateful session beans that manage their own transactions have more latitude than their counterparts. They may throw any exception, except an unchecked one, and still maintain their transactional state. This can be problematic and bean providers are advised to call EJBContext.setRollbackOnly to enforce transactional integrity.
