Choose between multiple connections and multiple sessions
Article ID: KB0089646
Updated On:
| Products | Versions |
|---|---|
| TIBCO Enterprise Message Service | - |
| Not Applicable | - |
Description
Resolution:
Since cpu and memory usage vary according to application design for the connections, unless you have a very good reason for using mulitple connections, we would recommend typical applications to use a single connection with multiple sessions.
The following explains the difference between connection and session, which will be helpful for you to decide which implementation you will choose.
Connections support concurrent use.
A connection serves several purposes:
* It encapsulates an open connection with a JMS provider. It typically represents an open TCP/IP socket between a client and the service provider software.
* Its creation is where client authentication takes place.
* It can specify a unique client identifier.
* It provides a ConnectionMetaData object.
* It supports an optional ExceptionListener object.
Because the creation of a connection involves setting up authentication and communication, a connection is a relatively heavyweight object. Most clients will do all their messaging with a single connection. Other more advanced applications may use several connections. The JMS API does not architect a reason for using multiple connections; however, there may be operational reasons for doing so.
On the other hand, 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:
* It is a factory for its message producers and consumers.
* It supplies provider-optimized message factories.
* It is a factory for TemporaryTopics and TemporaryQueues.
* It provides a way to create Queue or Topic objects for those clients that need to dynamically manipulate provider-specific destination names.
* It supports a single series of transactions that combine work spanning its producers and consumers into atomic units.
* It defines a serial order for the messages it consumes and the messages it produces.
* It retains messages it consumes until they have been acknowledged.
* It serializes execution of message listeners registered with its message consumers.
* It is a factory for QueueBrowsers.
A session can create and service multiple message producers and consumers.
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 thread.
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 close method.
As you can imagine, for a basic client application need, a Session can accommodate most requirements and much cheapter to create and manage than a Connection. Thus, multiple sessions over a single connection is the recommended use for most applications.
Since cpu and memory usage vary according to application design for the connections, unless you have a very good reason for using mulitple connections, we would recommend typical applications to use a single connection with multiple sessions.
The following explains the difference between connection and session, which will be helpful for you to decide which implementation you will choose.
Connections support concurrent use.
A connection serves several purposes:
* It encapsulates an open connection with a JMS provider. It typically represents an open TCP/IP socket between a client and the service provider software.
* Its creation is where client authentication takes place.
* It can specify a unique client identifier.
* It provides a ConnectionMetaData object.
* It supports an optional ExceptionListener object.
Because the creation of a connection involves setting up authentication and communication, a connection is a relatively heavyweight object. Most clients will do all their messaging with a single connection. Other more advanced applications may use several connections. The JMS API does not architect a reason for using multiple connections; however, there may be operational reasons for doing so.
On the other hand, 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:
* It is a factory for its message producers and consumers.
* It supplies provider-optimized message factories.
* It is a factory for TemporaryTopics and TemporaryQueues.
* It provides a way to create Queue or Topic objects for those clients that need to dynamically manipulate provider-specific destination names.
* It supports a single series of transactions that combine work spanning its producers and consumers into atomic units.
* It defines a serial order for the messages it consumes and the messages it produces.
* It retains messages it consumes until they have been acknowledged.
* It serializes execution of message listeners registered with its message consumers.
* It is a factory for QueueBrowsers.
A session can create and service multiple message producers and consumers.
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 thread.
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 close method.
As you can imagine, for a basic client application need, a Session can accommodate most requirements and much cheapter to create and manage than a Connection. Thus, multiple sessions over a single connection is the recommended use for most applications.
Issue/Introduction
Choose between multiple connections and multiple sessions
Feedback
Yes
No
Powered by
