1 Reply Latest reply on Mar 16, 2007 12:24 PM by colineberhardt

Stateless Session Beans - Static Variables - Concurrency and

trickyvail Mar 15, 2007 2:10 PM

I've been trying to find out what (if any) consequences there may be for implementing static class variables inside ejb3 stateless session beans. I've created some beans in this manner and they appear to function as I would expect on a standalone JBoss server, but I'm concerned that this technique may break clustering.

Essentially I'm trying to cache seldomly updated data (in the database) that is requested very frequently on the web front end.

@Stateless
public class CatalogBean implements Catalog
{
 static boolean current = false;
 static String data = null;

 public void refresh()
 {
 current = false;
 }

 public String getData()
 {
 if(! current)
 {
 update();
 }
 return data;
 }

 private void update()
 {
 data = getDataFromTheDatabase();
 current = true;
 }
}

Beans that are responsible for CRUD call the refresh method on this stateless bean - in turn updating their shared cache. My (hazy) understanding is that the ejb container is responsible to ensure that only one thread at a time can access a bean? Does this mean that different instances can be accessed concurrently - and therefore I could have syncronization issues? I suspect that static variables may be a bad idea - especially in a clustered environment.

Perhaps there is a different or recomended approach that I have not considered? Thank you in advance for all your comments and insights.

1. Re: Stateless Session Beans - Static Variables - Concurrency

colineberhardt Mar 16, 2007 12:24 PM (in response to trickyvail)

There are a couple of consequences to your method of caching data:

1. You certainly will hit concurrency issues. Your container will most likely hold a pool of SLSB instances, enabling it to service requests from a number of client. These request may result in concurrent access of your cache data.

2. This will certainly not work in a clustered environment. The different container instances will run under different JVMs. Static data is only shared between classes runnign in the same JVM.

SLSB are simply not designed to be used in this way. The JEE5 framework is designed in such a way that developers do not have to worry about the mechanics of concurrent accesses or clustering. You are breeaking this!

Are you sure that you need this cache which you have implemented? Have you executed performance tests and found that the system is slow?

Optimising for performance too early results in ver porr designs.

Are you aware fo the fact that Hibernate offers 3 levels of caching? I should imagine that your data will sit quite happily within the Hibernate L2 cache and that your database will not be repeatedly hit.

If you do test your system and find that the performance is poor, your first strtegy shoud be to try tuning teh system, not to hacjk together a cache!

Regards,
Colin E.
Actions