Acknowledgment modes of JMS sessions

Every session that is not transacted has an acknowledgment mode that determines how messages received by the application are acknowledged. Three acknowledgment modes are available, and the choice of acknowledgment mode affects the design of the application.

If a session is not transacted, the way that messages received by the application are acknowledged is determined by the acknowledgment mode of the session. The three acknowledgment modes are described in the following paragraphs:

AUTO_ACKNOWLEDGE

The session automatically acknowledges each message received by the application.

If messages are delivered synchronously to the application, the session acknowledges receipt of a message every time a Receive call completes successfully. If messages are delivered asynchronously, the session acknowledges receipt of a message every time a call to the onMessage() method of a message listener completes successfully.

If the application receives a message successfully, but a failure prevents acknowledgment from occurring, the message becomes available for delivery again. The application must therefore be able to handle a message that is re-delivered.

DUPS_OK_ACKNOWLEDGE

The session acknowledges the messages received by the application at times it selects.

Using this acknowledgment mode reduces the amount of work the session must do, but a failure that prevents message acknowledgment might result in more than one message becoming available for delivery again. The application must therefore be able to handle messages that are re-delivered.

Restriction: In AUTO_ACKNOWLEDGE and DUPS_OK_ACKNOWLEDGE modes, JMS does not support an application throwing an unhandled exception in a message listener. This means that messages are always acknowledged when the message listener returns, regardless of whether it was processed successfully (provided any failures are non-fatal and do not prevent the application from continuing). If you require finer control of message acknowledgment, use the CLIENT_ACKNOWLEDGE or transacted modes, which give the application full control of the acknowledgment functions.

CLIENT_ACKNOWLEDGE

The application acknowledges the messages it receives by calling the Acknowledge method of the Message class.

The application can acknowledge the receipt of each message individually, or it can receive a batch of messages and call the Acknowledge method only for the last message it receives. When the Acknowledge method is called all messages received since the last time the method was called are acknowledged.

In conjunction with any of these acknowledgment modes, an application can stop and restart the delivery of messages in a session by calling the Recover method of the Session class. Messages received but previously unacknowledged are re-delivered. However, they might not be delivered in the same sequence in which they were previously delivered. In the meantime, higher priority messages might have arrived, and some of the original messages might have expired. In the point-to-point domain, some of the original messages might have been consumed by another application.

An application can determine whether a message is being re-delivered by examining the contents of the JMSRedelivered header field of the message. The application does this by calling the getJMSRedelivered() method of the Message class.