Newsletter sign-up
View all newsletters

Enterprise Java Newsletter
Stay up to date on the latest tutorials and Java community news posted on JavaWorld

Sponsored Links

Optimize with a SATA RAID Storage Solution
Range of capacities as low as $1250 per TB. Ideal if you currently rely on servers/disks/JBODs

JavaWorld.com > Java Enterprise Edition >

Repair invalid cached services in the Service Locator pattern

The Verified Service Locator pattern ensures cached services' validity

By Paulo Caroli, JavaWorld.com, 07/05/02

  • Print
  • Feedback

The Service Locator pattern locates J2EE (Java 2 Platform, Enterprise Edition) services for clients and thus abstracts the complexity of network operation and J2EE service lookup as EJB (Enterprise JavaBean) Home and JMS (Java Message Service) component factories. The Service Locator hides the lookup process's implementation details and complexity from clients. To improve application performance, Service Locator caches service objects to eliminate unnecessary JNDI (Java Naming and Directory Interface) activity that occurs in a lookup operation.

When you opt to use the Service Locator pattern in J2EE development, you expect no side effects. However, cached services can be invalid, generating unexpected errors in your application. To avoid these errors, enhance the Service Locator pattern to neutralize potential problems with cached services. In this article, I present a way to empower the Service Locator pattern with a verification mechanism that recognizes and eliminates invalid cached services.

Context

Figure 1 shows the Service Locator pattern behavior.

Figure 1. Service Locator execution

For example, to acquire an EJB Home object for the first time, Service Locator first creates a JNDI initial context object and performs a lookup on the EJB Home object. Because this operation utilizes significant resources and because multiple clients repeatedly require the same EJB Home object, Service Locator caches the object, and consecutive calls use the cached service.

Problem

I used Service Locator in several projects without stumbling across any problems. However, when I used the pattern with my last project, the service invocation failed after the server restarted.

Figure 2 shows how a server restart generated the undesired error.

Figure 2. Service failure after a server restart

When a service has been invoked, Service Locator returns the cached service for consecutive invocations. In my project environment, the server restart invalidated the cached services; the client noticed this invalid service when it received an error while attempting to execute the service (Step 4 in Figure 2).

Unfortunately, Service Locator doesn't realize that it betrays the client by returning an invalid cached service. This is a contradictory situation: Service Locator, with its great benefits, brings this drawback. This article doesn't focus on the possible situations that invalidate the Service Locator's cached services; rather, it explores a solution for overcoming this problem.

You could address this situation in one of the following ways:

  • Don't use Service Locator: This approach solves the problem, but you lose the pattern's benefits.
  • Treat the error when it happens: With this approach, you add more code to the client code to solve the problem created by Service Locator; however, your reasoning for using Service Locator in the first place was to reduce code complexity. Furthermore, each different client will have to solve the same problem.
  • Use the proposed enhanced Service Locator instead: I explain this solution below in detail.


Solution

Enhance Service Locator by empowering it with a mechanism for periodically verifying the cached services.

  • Print
  • Feedback

Resources