Are messages thread-safe?

Jerry Smith

If the JMS specification required a thread-safe implementation for all objects, it would, in many situations, be a burden on programmers. The following objects support concurrent use:

  • Destination
  • ConnectionFactory
  • Connection

Session, on the other hand, is a single-threaded context that handles message-passing operations. A session serves as a message factory and it processes messages in serial order. One reason for the single-thread design is that a session is responsible for transaction-related operations.

Sessions are single-threaded contexts because a session is where the action is. In particular, a session is responsible for operations such as transaction handling and asynchronous message passing. Requiring client code that's related to asynchronous message reception to support concurrent use would have been especially burdensome.

Note that clients can use multiple sessions to partition client operations. For example, one client thread can drive one session and another client thread can drive another session. Each session object serializes execution of message listeners (the methods that handle asynchronously delivered messages). Thus, message listeners (handlers) can share session-related resources. Client resources (critical objects) outside the session, however, are the responsibility of the application designer, as always.