How to Handle Permanent Exceptions after EJB Deployment: a Proposal
Finally I found time for a technical log here at Java.net. This time I want to discuss a shortcoming of the EJB specification and how they can be fixed to make the life of EJB developers and application server administrators easier and the deployed applications more robust.
Originally the EJB specification assumed that the applications are deployed at startup of the application server and the environment remains stable for the time the server is up. With the broader acceptance of the J2EE application servers the dependencies between remote servers (DB, application servers, JMS etc) grows and a successful deployment does not mean that an application will run smoothly all the time. In some cases application server are just used to host application on the user’s computer and there is not full time administrator on duty.
Let us assume that an application contains one or more message driven beans (MDB) and they invoke other EJBs or resources to help execute the handling of a message. Now a resource used is becoming unavailable for a longer period of time and the message cannot be handled anymore. In the current specification then only thing the MDB can do is to either swallow the message and therefore lose all the pending message on the destination the MDB is registered on or it can rollback the message causing the server to resend the message immediately. The second option of course will put a drain on the server because every message will be resent until the message could be handled again or the server is putting the message away in some sort of a dead letter queue. Just imagine that a destination contains thousands of messages which are resent multiple times just to end up in a dead letter queue. What a waste of resources, isn’t it.
A similar problem occurs when a client access a stateless session bean (SLSB) because the SLSB instance is not created when the “create” method is invoked on the home interface but somewhere between the deployment and the first invocation of a business method on the SLSB instance. This means that any exception in the “setSessionContext” and “ejbCreate” method is not available to the client.
Both problems can be solved if the EJBContext would allow the EJB to inform the server about an unrecoverable error with a message and a Throwable instance. This allows the server to take the EJB and/or the entire application in question down and return an appropriate EJB- or RemoteException to a caller to inform about the original problem. The server then can inform the administrator about the problem or can try to restart the EJB/Application periodically (in the case of MDBs). Such a hook in the EJBContext could look like this:
public void reportException(String message, Throwable cause, int severity, int hintForServerHandling);
'Severity' will inform the server about how sever the exception is and the 'hintForServerHandling' gives the server an idea what to do like deactivating or shutting down the EJB or the entire application etc.
Bad Andy – Better Pizza