Threading in JMS

[rboston]

I'll try this question another way:

According to the spec, a Session object should NOT be used across threads.

I've got a JMS test with one consumer, one session that indicates onMessage is called from multiple server threads.

This goes against the spec !!!

Does anybody have an idea why this is happening and such.

thanks

[hchirino]

The onMessage() method is not part of the session object right? Spec is not being violated. If you use the session object from within the onMessage() method then YOU are violating the spec.

Regards,
Hiram

[rboston]

Dude

I didn't say I'm using the session object from within onMessage().

I said that according to the spec, a session defines a single threaded context. I had a program that for a single session and a single provider the system was using multiple threads to call onMessage().

[schaefera]

Hi

I don't think that the spec. says the JMS implementation is not allowed to use multiple thread to send messages asynchronously but YOU ARE NOT allowed to use a session other multiple threads (MessageProducer.send() or MessageConsumer.receive()).

Have fun - Andy

[rboston]

That's possible - this spec isn't always easy to interpret.

Here's the excerpt:

26 Java Message Service —Version 1.1 April 12, 2002
Multithreading
JMS could have required that all its objects support concurrent use. Since
support for concurrent access typically adds some overhead and complexity,
the JMS design restricts its requirement for concurrent access to those objects
that would naturally be shared by a multithreaded client. The remainder are
designed to be accessed by one logical thread of control at a time.
JMS defines some specific rules that restrict the concurrent use of Sessions.
Since they require more knowledge of JMS specifics than we have presented at
Table 2-2 JMS Objects that Support Concurrent Use
JMS Object Supports Concurrent Use
Destination YES
ConnectionFactory YES
Connection YES
Session NO
MessageProducer NO
MessageConsumer NO
2
this point, they will be described later. Here we will describe the rationale for
imposing them.
There are two reasons for restricting concurrent access to Sessions. First,
Sessions are the JMS entity that supports transactions. It is very difficult to
implement transactions that are multithreaded. Second, Sessions support
asynchronous message consumption. It is important that JMS not require that
client code used for asynchronous message consumption be capable of
handling multiple, concurrent messages. In addition, if a Session has been set
up with multiple, asynchronous consumers, it is important that the client is not
forced to handle the case where these separate consumers are concurrently
executing. These restrictions make JMS easier to use for typical clients. More
sophisticated clients can get the concurrency they desire by using multiple
sessions.