Speeding Up JNDI Lookups by Pooling Session Objects Speeding Up Object Creation Through Caching

Enhanced Support for Using WebLogic JMS with EJBs and Servlets 4-9

4.3.6 Monitoring Pooled Connections

You can use the Administration Console to monitor pooled connections. For more information, see JMS Servers: Monitoring: Active Pooled Connections in the Oracle WebLogic Server Administration Console Help.

4.4 Improving Performance Through Pooling

The automatic pooling of connections and other objects by the JMS wrappers means that it is efficient to write code as shown in Section 4.6.2, Sending a JMS Message In a Java EE Container. Although in this example the Connection Factory, Connection, and Session objects are created every time a message is sent, in reality these three classes work together so that when they are used as shown, they do little more than retrieve a Session object from the pool. ■ Section 4.4.1, Speeding Up JNDI Lookups by Pooling Session Objects ■ Section 4.4.2, Speeding Up Object Creation Through Caching ■ Section 4.4.3, Enlisting the Proper Transaction Mode

4.4.1 Speeding Up JNDI Lookups by Pooling Session Objects

The JNDI lookups of the Connection Factory and Destination objects can be expensive in terms of performance. This is particularly true if the Destination object points to a Foreign JMS Destination MBean, and therefore, is a lookup on a non-local JNDI provider. Because the Connection Factory and Destination objects are thread-safe, they can be looked up once inside an EJB or servlet at creation time, which saves the time required to perform the lookup each time. Inside a servlet, these lookups can be performed inside the init method. The Connection Factory and Destination objects may then be assigned to an instance variable and reused whenever a message is sent. Inside an EJB, these lookups can be performed inside the ejbCreate method and assigned to an instance variable. For a session bean, each instance of the bean will then have its own copy. Since stateless session beans are pooled, this method is also very efficient and is perfectly consistent with the Java EE specifications, because the number of a times that lookups occur is drastically reduced by pooling the JMS connection objects. Caching these objects in a static member of the EJB class may work, but it is discouraged by the Java EE specification. However, if these objects are cached inside the ejbCreate or init method, then the EJB or servlet must have some way to recreate them if there has been a failure. This is necessary because some JMS providers, like WebLogic JMS, may invalidate a Destination object after a server failure. So, if the EJB runs on Server A, and JMS runs on Server B, then the EJB on Server A will have to perform the JNDI lookup of the objects from Server B again after that server has recovered. The example, Section 4.6.1.5, PoolTestBean.java includes a sample EJB that performs this caching and re-lookup process correctly.

4.4.2 Speeding Up Object Creation Through Caching

Once Connection Factory object andor Destination object pooling has been established, it may be tempting to cache other objects, such as the Connection, Session, and Producer objects, inside the ejbCreate method. This will work, but it is not always the most efficient solution. Essentially, by doing this you are removing a Session object from the cache and permanently assigning it to a particular EJB, 4-10 Programming JMS for Oracle WebLogic Server whereas by using the JMS wrappers as designed, that Session object can be shared by other EJBs and servlets as well. Furthermore, the wrappers attempt to reestablish a JMS connection and create new session objects if there is a communication failure with the JMS provider, but this will not work if you cache the Session object on your own.

4.4.3 Enlisting the Proper Transaction Mode