Interesting.  So if you had an API that acquired data via Java remoting and
was potentially accessed by a couple thousand threads concurrently,  it
sounds like a pool of broker connections, each with an associated
ThreadLocal for session storage, might do the trick.  It would result in
some wasted storage since each connector would eventually end up with a
session for each client thread,  but that out of process communication cost
would only be incurred the first time a specific thread grabbed a connection
from the pool.   The JMS spec includes a reference to a SessionPool
interface, but it looks like it's intended for use in high-volume consumers,
not RPC-style clients.   Is that correct?

Thanks,
D.


Joe Fernandez wrote:
> 
> The 'temporary' destinations behave a little differently. A temporary
> destination's lifetime is that of the connection that created it. I'd
> recommend reusing session objects if you can. They, along with the
> Producer and Consumer objects, are lightweight objects, but creating and
> destroying them generates network traffic to and from the broker. 
> 
> Joe
> www.ttmsolutions.com
>   
> 
> 
> bsnyder wrote:
>> 
>> On Thu, Aug 7, 2008 at 12:41 PM, David Crisp <[EMAIL PROTECTED]>
>> wrote:
>>>
>>> Hi,
>>>     I have a quick question regarding the JMS spec and I was hoping to
>>> solicit
>>> feedback from our merry band of domain experts.
>>>
>>>     Given that Sessions are not thread-safe, if I'm creating a little
>>> client-side
>>> API that gets hit by a myriad of threads and do not want to synchronize
>>> the API points,  I need to create a new Session on the stack for each
>>> thread context.   Destinations ARE thread safe, but are created via a
>>> specific Session instance.   Given this, can I assume that destination
>>> instances
>>> remain valid even after the Session that created them is destroyed?  
>>> I've
>>> looked at
>>> the JMS spec and it seems fairly silent on this point.
>>>
>>> Thanks in advance,
>>> D.
>>>
>>> P.s.  I'm assuming this must be true given that Destination creation
>>> can't
>>> be cheap since it requires communication with the broker.
>> 
>> Yes, once a destination has been created, it will exist on the broker
>> even if the session that created it is destroyed. This is because the
>> session is simply used to interact with the broker and send it
>> commands.
>> 
>> Bruce
>> -- 
>> perl -e 'print
>> unpack("u30","D0G)[EMAIL PROTECTED]&5R\"F)R=6-E+G-N>61E<D\!G;6%I;\"YC;VT*"
>> );'
>> 
>> Apache ActiveMQ - http://activemq.org/
>> Apache Camel - http://activemq.org/camel/
>> Apache ServiceMix - http://servicemix.org/
>> 
>> Blog: http://bruceblog.org/
>> 
>> 
> 
> 

-- 
View this message in context: 
http://www.nabble.com/%28hopefully%29-simple-JMS-question-tp18877105p18878573.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.

Reply via email to