A Session object is a single-threaded context for producing and consuming
messages. Although it may allocate provider resources outside the Java
virtual machine (JVM), it is considered a lightweight JMS object.
A session serves several purposes:
A session can create and service multiple message producers and
One typical use is to have a thread block on a synchronous
MessageConsumer until a message arrives. The thread may then
use one or more of the Session's MessageProducers.
If a client desires to have one thread produce messages while others
consume them, the client should use a separate session for its producing
Once a connection has been started, any session with one or more
registered message listeners is dedicated to the thread of control that
delivers messages to it. It is erroneous for client code to use this session
or any of its constituent objects from another thread of control. The
only exception to this rule is the use of the session or connection
It should be easy for most clients to partition their work naturally
into sessions. This model allows clients to start simply and incrementally
add message processing complexity as their need for concurrency grows.
The close method is the only session method that can be
called while some other session method is being executed in another thread.
A session may be specified as transacted. Each transacted
session supports a single series of transactions. Each transaction groups
a set of message sends and a set of message receives into an atomic unit
of work. In effect, transactions organize a session's input message
stream and output message stream into series of atomic units. When a
transaction commits, its atomic unit of input is acknowledged and its
associated atomic unit of output is sent. If a transaction rollback is
done, the transaction's sent messages are destroyed and the session's input
is automatically recovered.
The content of a transaction's input and output units is simply those
messages that have been produced and consumed within the session's current
A transaction is completed using either its session's commit
method or its session's rollback method. The completion of a
session's current transaction automatically begins the next. The result is
that a transacted session always has a current transaction within which its
work is done.
The Java Transaction Service (JTS) or some other transaction monitor may
be used to combine a session's transaction with transactions on other
resources (databases, other JMS sessions, etc.). Since Java distributed
transactions are controlled via the Java Transaction API (JTA), use of the
session's commit and rollback methods in
this context is prohibited.
The JMS API does not require support for JTA; however, it does define
how a provider supplies this support.
Although it is also possible for a JMS client to handle distributed
transactions directly, it is unlikely that many JMS clients will do this.
Support for JTA in the JMS API is targeted at systems vendors who will be
integrating the JMS API into their application server products.