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