Consuming Messages in Transactions in the PubSub+ JCSMP API

To consume Guaranteed messages in a transaction, a client must create a consumer flow within the transacted session through one of the methods or functions listed below to bind to the destination endpoint that the messages are spooled to.

Guaranteed messages can then be received from the destination endpoint through the consumer flow either:

  • asynchronously, through a defined listener, called XMLMessageListener
  • synchronously, through individual receive calls. The calls required to synchronously consume messages in a transaction are listed below.

Consumers in a transacted session function the same as those in a non‑transacted session, except that the messages they receive are only acknowledged, and subsequently removed from the event broker, when a successful commit occurs for the transacted session. For example, calling XMLMessage.ackMessage() has no effect on transacted sessions. For information on how to receive Guaranteed messages synchronously or asynchronously, refer to Receiving Guaranteed Messages in the PubSub+ JCSMP API.

For JCSMP, by default when a consumer flow is created, it is in a stop state (that is, no message are received until the client application calls start()).

To create a consumer flow in a transacted session, use TransactedSession.createFlow(...) to acquire a FlowReceiver instance.

To synchronously consume messages in a transaction, use:

  • receive()—Receive the next available message, and waits until one is available.
  • receive(int timeoutInMillis)—Receive the next available message. If no message is available, the method waits until a set amount of time expires.
  • receiveNoWait()—Receive the next available message. If no message is available, this method returns null immediately.

When the following situations occur after the messages are consumed in a Transaction, but before a commit is made, those messages are still successfully committed:

  • The messages are removed from the event broker by an administrative action (that is, the messages are deleted from the spool).
  • The messages’ TTLs have expired. (Note that the commit succeeds whether or not expired messages are moved to a Dead Message Queue (DMQ).)