> Message Acknowledgement
> The interface specification for JMS requires that message delivery be guaranteed under many, but not all, circumstances. Figure 10 illustrates the basic structure of message delivery and acknowledgement.
> Figure 10 Message Delivery and Acknowledgement
> The following describes the steps in message delivery and acknowledgement:

> 1. | A message is sent from the message producer to the machine on which the EMS server resides.

> 2. | For persistent messages, the EMS server sends a confirmation to the producer that the message was received.

> 3. | The server sends the message to the consumer.

> 4. | The consumer sends an acknowledgement to the server that the message was received. A session can be configured with a specific acknowledge mode that specifies how the consumer-to-server acknowledgement is handled. These acknowledge modes are described below.

> 5. | In many cases, the server then sends a confirmation of the acknowledgement to the consumer.

> The JMS specification defines three levels of acknowledgement for non-transacted sessions:

> ● | CLIENT_ACKNOWLEDGE specifies that the consumer is to acknowledge all messages that have been delivered so far by the session. When using this mode, it is possible for a consumer to fall behind in its message processing and build up a large number of unacknowledged messages.

> ● | AUTO_ACKNOWLEDGE specifies that the session is to automatically acknowledge consumer receipt of messages when message processing has finished.

> ● | DUPS_OK_ACKNOWLEDGE specifies that the session is to "lazily" acknowledge the delivery of messages to the consumer. "Lazy" means that the consumer can delay acknowledgement of messages to the server until a convenient time; meanwhile the server might redeliver messages. This mode reduces session overhead. Should JMS fail, the consumer may receive duplicate messages.

> EMS extends the JMS acknowledge modes to include:

> ● | NO_ACKNOWLEDGE

> ● | EXPLICIT_CLIENT_ACKNOWLEDGE

> ● | EXPLICIT_CLIENT_DUPS_OK_ACKNOWLEDGE

> The acknowledgement mode is set when creating a Session, as described in Creating a Session.
> NO_ACKNOWLEDGE
> NO_ACKNOWLEDGE mode suppresses the acknowledgement of received messages. After the server sends a message to the client, all information regarding that message for that consumer is eliminated from the server. Therefore, there is no need for the client application to send an acknowledgement to the server about the received message. Not sending acknowledgements decreases the message traffic and saves time for the receiver, therefore allowing better utilization of system resources.

> | Sessions created in no-acknowledge receipt mode cannot be used to create durable subscribers. Also, queue receivers on a queue that is routed from another server are not permitted to specify NO_ACKNOWLEDGE mode.

> EXPLICIT_CLIENT_ACKNOWLEDGE
> EXPLICIT_CLIENT_ACKNOWLEDGE is like CLIENT_ACKNOWLEDGE except it acknowledges only the individual message, rather than all messages received so far on the session.
> One example of when EXPLICIT_CLIENT_ACKNOWLEDGE would be used is when receiving messages and putting the information in a database. If the database insert operation is slow, you may want to use multiple application threads all doing simultaneous inserts. As each thread finishes its insert, it can use EXPLICIT_CLIENT_ACKNOWLEDGE to acknowledge only the message that it is currently working on.
> EXPLICIT_CLIENT_DUPS_OK_ACKNOWLEDGE
> EXPLICIT_CLIENT_DUPS_OK_ACKNOWLEDGE is like DUPS_OK_ACKNOWLEDGE except it ’lazily" acknowledges only the individual message, rather than all messages received so far on the session.

Copyright © TIBCO Software Inc. All Rights Reserved.