activemq-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rob Davies <>
Subject Re: Is it ever OK to use a session *synchronously* from more than one thread?
Date Mon, 03 Mar 2008 11:41:45 GMT

On 29 Feb 2008, at 01:26, 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.
Yes - this fine within the JMS spec -section 4.4.6
> ----
> 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?
As long as the implementation is compatible with the JMS spec this is  
ok - and its certainly fine for ActiveMQ
> 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--tp15750184s2354p15750184.html
> Sent from the ActiveMQ - User mailing list archive at


Rob -Enterprise Open Integration

View raw message