Concurrent access to JMS session in servlet

Question

          We have a servlet that accepts a request from a browser,
          retrieves info from the request, places it in a JMS message and
          then sends the msg to a JMS Queue. We create all the JMS
          objects (connection, session, etc.) at init time (all these
          objects have class scope). There is only one session and I was
          wondering because servlets are multithreaded, while a request is
          being handled for one client, if there is a context switch in
          the middle of that client's send in order to handle another
          client's request, two different threads will be accessing the
          same session concurrently. I know the spec advises against
          this. Am I thining too much on this one????? All I have to do
          is synchronize the send call however I was just wondering if it
          was truely necessary.
          How are other people doing this out there?
          Let me know,
          Mark
          

Answer 1

Hi Mark,
          You are definitely not thinking too much on this one! Multi-threading
          session access is unsafe and is definitely against spec. Either
          synchronize
          access, or, if performance is an issue, make sure each simultaneous
          sender has its
          own session.
          The WebLogic JMS Performance white paper on dev2dev.bea.com
          contains an example of a producer pool that looks like it should map
          well to your use case.
          Tom, BEA
          Mark Drifdon wrote:
          > We have a servlet that accepts a request from a browser,
          > retrieves info from the request, places it in a JMS message and
          > then sends the msg to a JMS Queue. We create all the JMS
          > objects (connection, session, etc.) at init time (all these
          > objects have class scope). There is only one session and I was
          > wondering because servlets are multithreaded, while a request is
          > being handled for one client, if there is a context switch in
          > the middle of that client's send in order to handle another
          > client's request, two different threads will be accessing the
          > same session concurrently. I know the spec advises against
          > this. Am I thining too much on this one????? All I have to do
          > is synchronize the send call however I was just wondering if it
          > was truely necessary.
          > How are other people doing this out there?
          >
          > Let me know,
          > Mark