MDB Best Practices

A message-driven bean is a stateless, server-side, transaction-aware component that is driven by a Java message ( javax.jms.message ). As with standard JMS message consumers, message-driven beans receive messages from a JMS queue or topic and perform business logic based on the message contents.

Exception Handling in MDBs

Throwing application exceptions or remote exceptions inside an MDB's onMessage or bean methods is not a recommended practice. If any method throws such an exception, the EJB container immediately removes the EJB instance without calling ejbRemove() . This can be a major problem if you are removing or releasing any shared resources in the ejbRemove method. However, from the client perspective, the EJB still exists because future messages are forwarded to a new bean instance that the container creates.

Consider Using a Separate JMS Destination to Handle Poison Messages

MDBs with the Required transaction attribute can cause problems when aborting transactions. A transaction aborts because it was explicitly marked for rollback or because a system exception was thrown. One potential issue is known as the "Poison Message." For example, an MDB's onMessage() method has not received the valid input it was expecting. When the MDB encounters invalid input, the underlying logic might be to abort the transaction because the incoming parameter is invalid. When the JMS implementation delivers the message again in a new transaction, the process repeats. Poison messages cause continual rollback and redelivery of these messages, which is clearly not the expected behavior.

A good solution for this potential problem is to separate application errors from system errors. An application error, such as invalid data being passed to the MDB, should be handled by sending an error message to a JMS error destination. This enables the transaction to commit, and the Poison message leaves the system. This process also enables you to ensure that improper messages are not continually redelivered.

Consider Using DUPS_OK_ACKNOWLEDGE Mode

The EJB container automatically handles JMS message acknowledgements for MDBs. When an MDB is deployed in WLS with the Required transaction attribute, the container acknowledges the message when the transaction commits. Acknowledgement mode can be specified in the MDB's ejb-jar.xml deployment descriptor via the <jms- acknowledge -mode> tag. However, in case of failures, if your application can tolerate duplicate messages, using DUPS_OK_ACKNOWLEDGE mode is recommended. This mode performs better than AUTO_ACKNOWLEDGE because acknowledgements are less frequent. The WLS JMS implementation adds the NO_ACKNOWLEDGE and MULTICAST_NO_ACKNOWLEDGE modes, which can also be selected for message-driven EJBs. NO_ACKNOWLEDGE mode provides the best performance but the worst reliability because messages leave the system as soon as they are delivered. Acknowledgement mode is a trade-off between performance and reliability.