WebSphere Message Service Client for C/C++, Version 2.0.2 Operating Systems: AIX, Linux, Solaris, Windows

Message acknowledgement

Every session that is not transacted has an acknowledgement mode that determines how messages received by the application are acknowledged. Three acknowledgement modes are available, 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. The three acknowledgement modes are described in the following paragraphs:

XMSC_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 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.

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

Using this acknowledgement mode reduces the amount of work the session must do, but a failure that prevents message acknowledgement 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, XMS C/C++ 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 acknowledgement, use the CLIENT_ACKNOWLEDGE or transacted modes, which give the application full control of the acknowledgement functions.
XMSC_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 acknowledgement modes, an application can stop and restart the delivery of messages in a session by calling the Recover method of the Session class. Messages whose receipt was 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 Get JMSRedelivered method of the Message class.


Concept topic

Terms of Use | Rate this page

Last updated: 24 May 2011

(C) Copyright IBM Corporation 2005, 2011. All Rights Reserved.