Chapter 2 Working With Channels and Destinations : Changing the JMS Message Acknowledgment Mode

Changing the JMS Message Acknowledgment Mode
JMS channels support connection to TIBCO Enterprise Message Service destinations. The default acknowledgment mode is EXPLICIT.
You can set the acknowledgement mode in two ways:
The destination setting overrides the engine property setting.
To define the acknowledgment mode using an engine property, use one of the following, depending on whether you are using topics or queues:
be.channel.tibjms.topic.ack.mode acknowledgment_mode_number
be.channel.tibjms.queue.ack.mode acknowledgment_mode_number
Where acknowledgment mode number is one of the numbers that represent an acknowledgement mode, as shown in Table 6.
Note that in TIBCO Enterprise Message Service, mode names are slightly different. They are prefixed with TIBEMS-. See TIBCO Enterprise Message Service User’s Guide for more details.
Specifies that the session is to automatically acknowledge consumer receipt of messages when message processing has finished.
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.
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. However, should JMS fail, the consumer may receive duplicate messages.
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.
Like DUPS_OK_ACKNOWLEDGE (TIBEMS-DUPS-OK
-ACKNOWLEDGE) except it "lazily" acknowledges only the individual message, rather than all messages received so far on the session.
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.
Note  Sessions created in no-acknowledge receipt mode cannot be used to create durable subscribers.
Note  Also, queue receivers on a queue that is routed from another server are not permitted to specify NO_ACKNOWLEDGE mode.