You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@activemq.apache.org by stirlingc <sc...@alarmpoint.com> on 2008/02/29 02:26:43 UTC
Is it ever OK to use a session *synchronously* from more than one
thread?
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--tp15750184s2354p15750184.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.
Re: Is it ever OK to use a session *synchronously* from more than one thread?
Posted by Rob Davies <ra...@gmail.com>.
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/
Re: Is it ever OK to use a session *synchronously* from more than
one thread?
Posted by 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.