JMS Queue Receiver is a Starter process based on the receipt of a message for the specified JMS queue. There are different settings available for this palette and one is Acknowledge Mode. This setting is available under the configuration tab of the JMS Queue Receiver and we have 8 types of Acknowledge modes are available.
As you know a queue can have multiple receivers and we need to make sure the load balancing of incoming messages, these properties are useful. For e.g If we set the Acknowledge Mode field to “Auto” on the Configuration tab of the JMS Queue Receiver, the process starter confirms messages as it receives them. Consider we have two process engine for this queue and one of them got started late, this can lead to the first process engine receiving all queue messages and start processing them, depending upon how the engine’s Max Jobs and Activation Limit properties are set.
Now let discuss on each mode.
the message is automatically acknowledged when it is received by a process engine. But it can lead to the above-mentioned issue. Also if the process engine goes down for some reason we will lose the message it got confirmed already.
When this mode is specified, we need to confirm each message explicitly by using the Confirm activity at a later point. If the message is not confirmed or if the engine goes down while processing the message will stay in the queue. We will have an additional setting (Max Sessions) on this mode which specifies how many messages can be received by a process engine. Once a process engine reaches the maximum number of sessions, another one can begin to accept incoming messages. A process engine cannot receive more messages until the messages have been acknowledged by using the Confirm activity. Once the message is acknowledged, the session is released and the process engine can accept a new message.
As we can acknowledge the messages using confirm activity at a later point, we can ensure the receipt of each incoming messages on the queue.
Max Sessions setting is available for Transactional and Local Transactional modes as well.
This mode is only available for TIBCO Enterprise Message Service. a message which is not acknowledged using the Confirm activity before the process instance ends will be redelivered instead of all messages in the session. The session is not blocked and one session handles all incoming messages for each process instance.
This mode is also only available for TIBCO Enterprise Message Service. a message which is not acknowledged using the Confirm activity before the process instance ends will be redelivered instead of all messages in the session. The session is not blocked and one session handles all the incoming messages for each process instance. The messages, however, would be lazily acknowledged.
As the name says, the message is not acknowledged when it is received. I never used this mode until now and not sure why we need it.
The message is acknowledged automatically when it is received. JMS provides this mode for lazy acknowledgement, but TIBCO ActiveMatrix BusinessWorks acknowledges messages upon receipt.
The transactional mode is used when a transaction that can process JMS messages is included in the process definition. The message is acknowledged when the transaction commits. The Local Transactional mode is used when a transaction involves only JMS messages.
As a personal choice, I always have chosen the ‘Client’ Acknowledge mode in my projects.
Please let me know your feedback in the comment sections.