Managing Client Access

Implementing a Singleton in EJB

The Singleton pattern is a useful design pattern applied to control the number of instances of a particular class that exist in an application. It's most often used to limit a class to being instantiated only once. The idea is that certain services or heavyweight resources should be managed using a single class instance. Singletons have been used for many years and in languages other than Java. However, because the EJB container has control over the system, including the activation and passivation of instances, there are some inherent differences that must be recognized and understood when attempting to implement the Singleton pattern using enterprise beans. First, let's look at a class fragment that illustrates how a Singleton is usually implemented:

 public class MySingleton {     // The one and only instance      private static MySingleton _instance;      // Private constructor used by getInstance only      private MySingleton() {       // construct object here . . .      }      // Synchronized to prevent multiple threads from entering      public static synchronized MySingleton getInstance() {       if (_instance==null) {       _instance = new MySingleton();        }        return _instance;      }      // Remainder of class definition . . .    } 

In a Singleton class, there's usually a single static reference to the class and a static method that clients can call to get a reference to this instance. In the MySingleton class, clients get a reference to the single instance of the class by calling the getInstance method.

There are several problems with using Singleton objects with EJB applications. The first problem is that an EJB server may start multiple JVMs. A Singleton is supposed to be loaded once per application, but if there is more than one JVM in the application, you can't be guaranteed of having a single instance. Some EJB servers also pool JVMs and start and stop JVMs as if they were threads. You have to understand that your Singleton might have to be reinitialized frequently. Many EJB developers also recommend that you avoid Singletons that hold state because of the potential of having multiple JVMs loaded by the container. If this occurs, you can't guarantee that the state stored in each instance of the Singleton is the same across JVMs.

The traditional use of a Singleton is to manage access to a resource. Even if a Singleton class doesn't hold state, using one to control access to a resource in an EJB application still isn't appropriate because the container is responsible for resource management.

Having said all this, there are ways that EJB developers are using Singleton-like approaches to get the intended result. One recommended approach is to implement the functionality desired from a Singleton as a CORBA or RMI object and bind it in the JNDI namespace. All clients can use JNDI to look up this object and use it.