Newsletter sign-up

View all newsletters

Sign up for our technology specific newsletters.

Enterprise Java

Email Address:

When is a singleton not a singleton?

Avoid multiple singleton instances by keeping these tips in mind

By Joshua Fox, JavaWorld.com, 01/12/01

Page 3 of 6

For example, only the EJB container decides how and when to create EJB objects or to recycle existing ones. The EJB may exist in a different VM from the code that calls it. Moreover, a single EJB can be instantiated simultaneously in several VMs. For a stateless session bean, multiple calls to what appears, to your code, to be one instance could actually be calls to different instances on different VMs. Even an entity EJB can be saved through a persistence mechanism between calls, so that you have no idea what instance answers your method calls. (The primary key that is part of the entity bean spec is needed precisely because referential identity is of no use in identifying the bean.)

The EJB containers' ability to spread the identity of a single EJB instance across multiple VMs causes confusion if you try to write a singleton in the context of an EJB. The instance fields of the singleton will not be globally unique. Because several VMs are involved for what appears to be the same object, several singleton objects might be brought into existence.

Systems based on distributed technologies such as EJB, RMI, and Jini should avoid singletons that hold state. Singletons that do not hold state but simply control access to resources are also not appropriate for EJBs, since resource management is the role of the EJB container. However, in other distributed systems, singleton objects that control resources may be used on the understanding that they are not unique in the distributed system, just in the particular VM.

Multiple singletons simultaneously loaded by different class loaders

When two class loaders load a class, you actually have two copies of the class, and each one can have its own singleton instance. That is particularly relevant in servlets running in certain servlet engines (iPlanet for example), where each servlet by default uses its own class loader. Two different servlets accessing a joint singleton will, in fact, get two different objects.

Multiple class loaders occur more commonly than you might think. When browsers load classes from the network for use by applets, they use a separate class loader for each server address. Similarly, Jini and RMI systems may use a separate class loader for the different code bases from which they download class files. If your own system uses custom class loaders, all the same issues may arise.

If loaded by different class loaders, two classes with the same name, even the same package name, are treated as distinct -- even if, in fact, they are byte-for-byte the same class. The different class loaders represent different namespaces that distinguish classes (even though the classes' names are the same), so that the two MySingleton classes are in fact distinct. (See "Class Loaders as a Namespace Mechanism" in Resources.) Since two singleton objects belong to two classes of the same name, it will appear at first glance that there are two singleton objects of the same class.

Singleton classes destroyed by garbage collection, then reloaded

When a singleton class is garbage-collected and then reloaded, a new singleton instance is created. Any class can be garbage-collected when no other object holds reference to the class or its instances. If no object holds a reference to the singleton object, then the singleton class may disappear, later to be reloaded when the singleton is again needed. In that case, a new singleton object will be created. Any static or instance fields saved for the object will be lost and reinitialized.

 

Improve efficiency with Visual Studio(r) 2010 Beta 2. - Microsoft

About Us | Advertise | Contact Us | Terms of Service/Privacy

Copyright, 2006-2008 Network World, Inc. All rights reserved.