Related Topics: Java EE Journal, Java Developer Magazine

J2EE Journal: Article

Caching EJB Home Objects - For the sake of performance

Caching EJB Home Objects - For the sake of performance

The Java Naming and Directory Interface (JNDI) is an Application Programming Interface (API) used to locate resources registered in the naming service of a Java 2 Platform Enterprise Edition (J2EE) server such as IBM WebSphere Application Server version 5. The JNDI lookup process is an expensive operation and should be performed judiciously.

Caching of EJB home objects is a recommended approach to minimizing performance costs. This article will show the performance benefits of implementing this practice in a J2EE-centric application.

The application will consist of a servlet interacting with an EJB object. For learning purposes, our exercise uses IBM WebSphere Studio Application Developer version 5.

The EJB of Interest
A simple stateless session EJB (2.0) will provide the necessary features to perform this exercise. The following implementation is intentionally simple, so as not to lose sight of our goal. (see Listing 1)

The code consists of the standard EJB methods, along with a simple custom business method named "square". The method returns the square value of the parameter.

Expose the business method by promoting it to the remote interface. Once the method has been promoted, generate the deploy and RMIC (Remote Method Invocation Compiler) code. It is a good practice to test the implementation; in this case, leverage the Universal Test Client (UTC) to unit-test the EJB method (see Figure 1).


Invoking Externally
The servlet code in this article will invoke the remote method of the newly created EJB. The first sample shows an inefficient noncaching approach (see Listing 2).

A JNDI Lookup
Figure 2 shows three invocations of our servlet. Notice that the EJB home is looked up three times. You should note that the time burden associated with these lookups can be exasperated further if our client application is sitting on a different physical server from the one that hosts our EJBs. In such a setup (which is quite common), the temporal burdens of the lookup process are augmented by the latency of the underlying network.


Packing Our EJB Homes and Relocating to the Servlet init Method
We are now going to polarize our EJB lookup code to the init method for strategic purposes. You may recall that the init method of a servlet is called when the servlet class is first loaded. Depending on how we configure our servlet with our application server, we can opt to have the servlet class loaded either when our user first invokes the URL that corresponds to our servlet (think of a just in time–like approach) or when our server is first started.

By default, a servlet class will not be loaded upon startup of the server. You can change this by modifying the Web deployment descriptor (web.xml file). This can be done graphically, as shown in Figure 3 by checking the "Load on startup" option for the servlet.


Listing 3 reflects the changes necessary to implement the caching logic. Pay particular attention to the EJB home lookup code in the servlet init method of our servlet.

Now that our lookup code is in the init method, the lookup will occur only once, regardless of the number of invocations of our servlet. This can be shown by a simple inspection of our server console (see Figure 4), which shows our servlet being invoked three times. Notice the EJB home is looked up only once and is cached for future use.


In this article, we've studied the practice of caching EJB homes. This technique can speed up the use of EJBs in your applications. As the lookup process of EJB homes can be a time-consuming one, it makes good sense to try to store or cache the homes of the EJBs looked up, thereby looking up a given EJB's home only once.

As you have seen in this article, in a Web application using Java servlets, the init method serves as an ideal location for performing the caching of EJB home objects. However, it is a good possibility that you are dealing with a more complex setup in which multiple servlets are trying to access the same EJBs. In such a setup, you should consider leveraging a singleton design pattern. We'll do this in an upcoming sequel to this article.

Comments (0)

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.