ONJava.com -- The Independent Source for Enterprise Java
oreilly.comSafari Books Online.Conferences.


AddThis Social Bookmark Button

Designing Messaging Applications with Temporary Queues
Pages: 1, 2

Some Considerations for the Client Side When Using Temporary Queues

The session should be closed as soon as processing is completed so that TemporaryQueues will be deleted on the server side. While the JMS session doesn't support concurrency, this can be implemented with connection objects. A session is a single-threaded context to produce and consume the temporary messages. According to the JMS specification:

A session supports transactions and it is difficult to implement transactions that are multithreaded; a session should not be used concurrently by multiple threads.

Even though you are not using a transacted session, you are still required to coordinate individual sessions to implement concurrent processing. The only method in the session object method that can be concurrently called is close(). Threads are good candidates for blocking calls since they could be executed concurrently.

There is no need to close the consumers (QueueReceiver) of a closed session. As soon as the connection that created the temporary queue is closed, all the constituents of the closed connection and session are closed. Relying on garbage collection to eventually reclaim these resources may not be timely enough, especially in the case of JMS resources that are created outside of JVM.

Code Example

The following code excerpt shows how to create Temporary Destinations. We use common interfaces like Session as opposed to specific domain constructs like QueueSession or TopicSession. Sun encourages using common interfaces without programming specific to a single message domain so that the JMS application is domain-independent.

<font color=
"blue">/** Get the Initial Context Factory */</font>
Hashtable env              = new Hashtable();
String conFactoryClass     = "VendorSpecificCFC";
String url                 = "MyServer:port";
env.put(Context.INITIAL_CONTEXT_FACTORY, conFactoryClass);
env.put(Context.PROVIDER_URL, url);
env.put(Context.SECURITY_PRINCIPAL, "userid" );
env.put(Context.SECURITY_CREDENTIALS, "password");
Context                    = new InitialContext(env);

<font color=
"blue">/**Access the resources by looking up the JNDI
/**QueueConnectionFactory is a Factory for QueueConnection
javax.jms.ConnectionFactory qcf   =
javax.jms.Connection qConnection  =
  (QueueConnection)qcf.createConnection("userid", "password");
javax.jms.Queue myQueue           =
javax.jms.Topic myTopic           =

<font color="blue">/**TopicConnectionFactory is a Factory for
TopicConnection Object*/</font>
javax.jms.ConnectionFactory tcf       =
javax.jms.TopicConnection tConnection =
   (TopicConnection)tcf.createConnection("userid", "password");

<font color="blue">/**Create a Session using Connection
javax.jms.Session qSession                =
javax.jms.Session tSession                =
        tConnection.createSession(false, Session.AUTO_ACKNOWLEDGE);

<font color=
"blue">/**Create the Temporary Destinations using the Session
javax.jms.Queue replyQueue = qSession.createTemporaryQueue();
javax.jms.Topic replyTopic = tSession.createTemporaryTopic();


Temporary destinations are a useful tool in message-driven architectures. They have the distinction of being lightweight, and they allow applications to efficiently scale because you can easily expand the number available at runtime. Static destinations must be created in advance and, although useful in other ways, do not offer you this same flexibility. Because of this, temporary destinations are preferable to static destinations despite the extra work required to set up the communication between the sender and receiver.


Thanks to Ron Gates and the ONJava team for proofreading this article.


  1. JMS Specification
  2. JMS Tutorial
  3. J2EE 1.3 Specification
  4. Sun Java System Message Queue

Thakur Thribhuvan is a senior software engineer at Southwest Airlines with 11 years of experience in design and development. He has been working with Java since its inception, and with JMS since 1999.

Return to ONJava.com.