1 Reply Latest reply on Jul 3, 2012 2:53 PM by Tom B

    Caching JMS Connection,Session,Producers

      I read a very interesting articles regarding JMS caching


      that made me question if i use JMS in a proper way for sending messages
      (for MDB's is easy to specify the number of consumers and I assume there connections are handled by the container and is good practice)

      First scenario is s local lookup:

      When i want to send JMS messages from a stateless session bean :

      Context ctx = new InitialContext();
      QueueConnectionFactory queueConnectionFactory = (QueueConnectionFactory) ctx.lookup("jms.apps.QueueConnectionFactory");
      Connection conn = queueConnectionFactory.createConnection();
      Session session = conn.createSession(false, Session.AUTO_ACKNOWLEDGE);
      Destination destination = (Destination) ctx.lookup(queueName);
      MessageProducer myMsgProducer = session.createProducer(destination);
      TextMessage m = session.createTextMessage(message);

      Is this ok ?

      I mean on each call there is this sequence ==>


      In thee article it writes (but is for JBOSS) :

      "The reason is, when you use the JMS API from inside an EJB (including an MDB), or a servlet, (or a MBean in JBoss), then when you call createConnection() or createSession() on your JMS connection factory or JMS connection, you're not actually making those calls on a real JMS connection factory or JMS connection."

      Is this valid for Weblogic ?

      Scenario 2: Using a remote InitialContext : is there a big penalty for accessing that conn factory remotely (or is by default some cache,optimzation done)?

        • 1. Re: Caching JMS Connection,Session,Producers
          Tom B
          Basically, the answer is yes: a WebLogic app server will 'secretly' pool JMS resources. That said, it's a good idea for apps to cache CF and dest references as it is expensive to repeatedly look them up in JNDI - regardless of whether the JNDI context is local or remote. (It is a common practice to use remote contexts, the links below detail best practices for wiring them into WebLogic.) I think it's also a good idea to refresh CF and dest references on an error. Also, in your sample code, there's no need to call "connection.start()" - as it has no effect on message production.

          Here's the related WebLogic documentation:

          Enhanced Support for Using WebLogic JMS with EJBs and Servlets
          There's a nice EJB 3.0 sample at the very end of this chapter. I recommend doing two things slightly differently than the sample: (1) Do not rethrow the exception to cause redelivery as this expensively forces the bean to be destroyed and recreated, instead force a transaction rollback using the EJB context - that said, rethrowing is unavoidable with non-transactional MDBs as there's no equivalent to a rollback request in the non-transactional case, and (2) Set targetDest and targetCF to null in the exception handler to force them to be refreshed on an error.

          Integrating Remote JMS Providers

          Programming Message-Driven Beans