JMS Specification note

1. A connection’s delivery of incoming messages can be temporarily stopped
using its stop() method. It can be restarted using its start() method. When the
connection is stopped, delivery to all the connection’s MessageConsumers is
inhibited: synchronous receives block, and messages are not delivered to
MessageListeners.
If MessageListeners are running when stop is invoked, stop must wait until all
of them have returned before it may return. While these MessageListeners are
completing, they must have the full services of the connection available to
them.
When connection close is invoked it should not return until message
processing has been shut down in an orderly fashion. This means that all
message listeners that may have been running have returned, and that all
pending receives have returned.
If a connection is closed, there is no need to close its constituent objects. The
connection close is sufficient to signal the JMS provider that all resources for
the connection should be released.
Closing a connection does NOT force an
acknowledgement of client-acknowledged sessions.
2.
If a session is transacted, message acknowledgment is handled automatically
by commit, and recovery is handled automatically by rollback.
If a session is not transacted, there are three acknowledgment options, and
recovery is handled manually:
DUPS_OK_ACKNOWLEDGE
AUTO_ACKNOWLEDGE
CLIENT_ACKNOWLEDGE
3.
JMS providers must never produce duplicate messages. This means that a
client that produces a message can rely on its JMS provider to insure that
consumers of the message will receive it only once. No client error can cause a
provider to duplicate a message.