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
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.
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.
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:
Enhance Service Locator by empowering it with a mechanism for periodically verifying the cached services.