Re: Is it ever OK to use a session *synchronously* from more than one thread?

[tpounds <tr...@gmail.com>]

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.