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. Session).
-Trevor 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: > > http://www.nabble.com/Re%3A-Help%21-Missing-messages-in-Multithreaded-producer-p12535029s2354.html > > 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: http://www.nabble.com/Is-it-ever-OK-to-use-a-session-*synchronously*-from-more-than-one-thread--tp15750184s2354p15784127.html Sent from the ActiveMQ - User mailing list archive at Nabble.com.
