Service Locator problems...

Hi, I have encountered the following problems with Service Locator, any help/advice appreciated....

We are using a Service Locator (simple java class) in the web tier (Business Delegate) and the application tier (Session Facades) for all of the ejb context lookups. During performance testing we found that the Singleton Service Locator was a bottle neck, we hit the server with 10 simultaneous transactions, and 30% failed because they were contending for the shared resource of the ServiceLocator instance. As a solution, I created a pool of 30 Service Locators, and rotated the dolling out of the instances, and I no longer had this problem on the web tier. However I still have this problem in the application tier as I do not currently have such a thing as session state on the application tier, and I'm not guaranteed the same Service Locator instance throughout the thread.

Questions I have are:

1. Can I make the Service Locator threaded if it is to be used by ejb's in the application tier? I have heard disparate opinions about whether this is possible.

2. How have others solved this? I can't find anything in this forum about this.

And while I'm here...

I've also had problems where the cached homes have become stale. Have others solved this by putting a time limit on the data or has anyone tried something more sophisticated.

[1396 byte] By [bethpierce] at [2007-9-27 1:02:02]
# 1

What kind of shared state are you talking about ? A ServiceLocator should not

hold ANY read / write shared state. ( outside of the locator itself for lookups ).

Most application servers that I know of have implemented fail over in their home

interfaces. Synchronising on a HashMap or something of the sort as a cache for

your lookups shouldn't case such a performance propblem. What is your current

situation? Depending on you Application Servers ClassLoading architecture, you

maybe dealing with 2 instances of your ServiceLocator.

Regards,

TK.

TravisK at 2007-7-4 18:21:23 > top of Java-index,Other Topics,Patterns & OO Design...
# 2

I can't see why the ServiceLocator ended up becoming the bottleneck. You may need to relook your implementation strategy because with the right implementation, your Home object should never get stale. Try implementing a ServiceLocator class with a series of Static methods that can return the different Home objects. Look up the JNDI entry every time, no need to cache any Home objects. In other words, the service locator class will not hold state of any kind. We have implemented this strategy and it works fine even under tough load conditions.

Regards, Venky

venkrishy at 2007-7-4 18:21:23 > top of Java-index,Other Topics,Patterns & OO Design...