Message Acknowledgment
The EJB container automatically handles JMS message acknowledgment for message-driven EJBs. When a message-driven EJB is deployed with the Required transaction attribute, the container acknowledges the message when the transaction commits.
A message-driven EJB deployed as NotSupported or with bean-managed transactions uses AUTO_ACKNOWLEDGE. Like other asynchronous JMS message consumers, the acknowledgment is performed when the onMessage method returns.
Message-driven beans may also specify the DUPS_OK_ACKNOWLEDGE mode with the <jms-acknowledge-mode> tag in the ejb-jar.xml deployment descriptor. This acknowledgment mode enables the underlying JMS implementation to lazily acknowledge messages.
DUPS_OK_ACKNOWLEDGE performs better than AUTO_ACKNOWLEDGE because acknowledgments are less frequent, but the application must be able to tolerate duplicate messages in the case of failure.
Message-driven EJB writers should also be aware that even AUTO_ACKNOWLEDGE can cause a duplicate message to be delivered. This occurs if the JMS implementation fails after the onMessage method returns but before the acknowledgment completes. This case is covered in Chapter 7.
The WebLogic JMS implementation adds the NO_ACKNOWLEDGE and MULTICAST_NO_ACKNOWLEDGE modes that may also be selected for message-driven EJBs. NO_ACKNOWLEDGE provides the best performance but the worst reliability because messages leave the system as soon as they are delivered. MULTICAST_NO_ACKNOWLEDGE sends messages to a JMS topic over IP multicast. These acknowledgment modes are covered in detail in Chapter 7.
The acknowledgment mode is a trade-off between performance and reliability. The strongest delivery guarantee is the Required transaction attribute, which ensures that the message receipt participates in JTA transaction. The NO_ACKNOWLEDGE and MULTICAST_NO_ACKNOWLEDGE modes provide the highest message throughput because messages are not retained after delivery.