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:
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.
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:
http://www.nabble.com/Is-it-ever-OK-to-use-a-session-*synchronously*-from-more-than-one-thread--tp15750184s2354p15750184.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.
cheers,
Rob
http://open.iona.com/ -Enterprise Open Integration
http://rajdavies.blogspot.com/
