Nontransacted Sessions
Nontransacted Sessions
In transacted sessions (see
happens automatically when a transaction is committed. If a transaction is rolled back, all
consumed messages are redelivered.
In nontransacted sessions, when and how a message is acknowledged depend on the value
specified as the second argument of the createSession method. The three possible argument
values are as follows:
Session.AUTO_ACKNOWLEDGE
: The session automatically acknowledges a client's receipt of a
message either when the client has successfully returned from a call to receive or when the
MessageListener
it has called to process the message returns successfully. A synchronous
receive in an AUTO_ACKNOWLEDGE session is the one exception to the rule that message
consumption is a three-stage process as described earlier.
In this case, the receipt and acknowledgment take place in one step, followed by the
processing of the message.
Session.CLIENT_ACKNOWLEDGE
: A client acknowledges a message by calling the message's
acknowledge
method. In this mode, acknowledgment takes place on the session level:
Acknowledging a consumed message automatically acknowledges the receipt of all
messages that have been consumed by its session. For example, if a message consumer
consumes ten messages and then acknowledges the fifth message delivered, all ten messages
are acknowledged.
Session.DUPS_OK_ACKNOWLEDGE
: This option instructs the session to lazily acknowledge the
delivery of messages. This is likely to result in the delivery of some duplicate messages if the
JMS provider fails, so it should be used only by consumers that can tolerate duplicate
messages. (If the JMS provider redelivers a message, it must set the value of the
JMSRedelivered
message header to true.) This option can reduce session overhead by
minimizing the work the session does to prevent duplicates.
If messages have been received from a queue but not acknowledged when a session terminates,
the JMS provider retains them and redelivers them when a consumer next accesses the queue.
The provider also retains unacknowledged messages for a terminated session that has a durable
TopicSubscriber
. (See
messages for a nondurable TopicSubscriber are dropped when the session is closed.
If you use a queue or a durable subscription, you can use the Session.recover method to stop a
nontransacted session and restart it with its first unacknowledged message. In effect, the
session's series of delivered messages is reset to the point after its last acknowledged message.
The messages it now delivers may be different from those that were originally delivered, if
messages have expired or if higher-priority messages have arrived. For a nondurable
TopicSubscriber
, the provider may drop unacknowledged messages when its session is
recovered.
The sample program in the next section demonstrates two ways to ensure that a message will
not be acknowledged until processing of the message is complete.
Creating Robust JMS Applications
Chapter 31 · The Java Message Service API
937
