activemq-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From tpounds <>
Subject Re: Is it ever OK to use a session *synchronously* from more than one thread?
Date Sun, 02 Mar 2008 06:41:28 GMT

Only the Destination, Connection, and ConnectionFactory objects support
concurrent usage per the JMS 1.1 spec. If you want to share a Sessions
across multiple threads then you should create an object to manage
synchronous access to any JMS objects which do not support this (i.e.


stirlingc wrote:
> Hello,
> The JavaDoc for ActiveMQSession states that it is a single-threaded class. 
> Mr. Strachan re-iterates in this message about ensuring that each thread
> has its own session and producers/consumers:
> However, is it acceptable for thread A to create  a session S and pass it
> to thread B?  Thread A never accesses S again, and thread B is responsible
> for closing S.  In other words, S is used in a single-threaded manner, but
> its user is a different thread from the one that created it.
> ----
> The reason I ask is I have a scenario where I want queue messages to be
> processed in parallel by a self-managed thread pool (i.e., the number of
> threads grows and contracts depending on load).  The wrinkle is that I
> want each thread to be able to roll back its assigned message; in other
> words, each thread has to have its own session.
> I've thought about using a dispatcher thread that creates a session and
> then calls MessageConsumer.receive() to block until a message arrives. 
> Upon message arrival, the dispatcher passes the session and message to a
> pooled thread for processing.  The pooled thread is responsible for
> committing/rolling back and closing the session.  As soon as the pooled
> thread starts, the dispatcher thread creates a new session/consumer, and
> the process repeats.
> In this scenario, a session is only used by a single pooled thread, but it
> is created by the dispatcher thread.  Is this OK or are there ThreadLocals
> or other tricks that might be broken by doing this?
> I've seen a similar solution where the dispatcher thread uses
> MessageListener.onMessage(), but I think that is even more problematic
> since the ActiveMQSession JavaDoc specifically mentions that the caller of
> onMessage() must be the sole user of the session (which is violated by the
> pooled thread).
> The only other solution I can think of is to launch all my pooled threads
> at once and have each of them create their own session/consumer and block
> on receive().  Each pooled thread would then completely process a message
> before re-blocking on another receive().  However, this does not allow me
> to use an expanding/contracting thread pool.
> Thanks for the help!

View this message in context:*synchronously*-from-more-than-one-thread--tp15750184s2354p15784127.html
Sent from the ActiveMQ - User mailing list archive at

View raw message