Every session that is not transacted has an acknowledgement mode that determines how messages received by the application are acknowledged. There are three possible acknowledgement modes, and the choice of acknowledgement mode affects the design of the application.
The information in this topic is relevant only if an application connects to a WebSphere MQ queue manager or a WebSphere service integration bus. The information is not relevant for a real-time connection to a broker.
XMS uses the same mechanism for acknowledging the receipt of messages that JMS uses.
If a session is not transacted, the way that messages received by the application are acknowledged is determined by the acknowledgement mode of the session. There are three acknowledgement modes:
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 to a C application, the session acknowledges receipt of a message every time a call to a message listener function completes successfully. For a C++ application, 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 acknowledgement from occurring, the message becomes available for delivery again. The application must therefore be able to handle a message that is re-delivered.
Using this acknowledgement mode reduces the amount of work the session needs to do, but a failure that prevents acknowledgement from occurring might mean that more than one message becomes available for delivery again. The application must therefore be able to handle any messages that are re-delivered.
The application can acknowledge the receipt of each message individually. Alternatively, the application can receive a batch of messages and call the Acknowledge method only for the last message it receives. Calling the Acknowledge method causes acknowledgement of all messages received since the last time the method was called.
In conjunction with any of these acknowledgement modes, an application can stop and restart the delivery of messages in a session by calling the Recover method of the Session class. Those messages whose receipt was previously unacknowledged are re-delivered. However, these messages might not be delivered in the same sequence that they were previously delivered. In the meantime, higher priority messages might have arrived, and some of the original messages might have expired. And, 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 Get JMSRedelivered method of the Message class.