4 Replies Latest reply on Aug 19, 2002 6:09 PM by rboston

    Threading in JMS

    rboston Newbie

      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.


        • 1. Re: Threading in JMS
          Hiram Chirino Expert

          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.


          • 2. Re: Threading in JMS
            rboston Newbie


            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().

            • 3. Re: Threading in JMS
              Andreas Schaefer Apprentice


              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

              • 4. Re: Threading in JMS
                rboston Newbie

                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
                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
                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