This week's book giveaway is in the OO, Patterns, UML and Refactoring forum. We're giving away four copies of Refactoring for Software Design Smells: Managing Technical Debt and have Girish Suryanarayana, Ganesh Samarthyam & Tushar Sharma on-line! See this thread for details.
As we all know that Singleton Pattern is a design pattern used to restrict the instantiation of a class to a single object i.e. we can create only one object for a class.
My doubt is that... Does this applies for a JVM. i.e. In a JVM instance will there be only one instance of a singleton class.
To make it more clear I will take the example of a Tomcat application. Suppose I have a java web project called singledemo with a Singleton class in it. I deploy the same project in a tomcat as two different applications - singledemo and singledemo-test.
I run both the applications and execute the code to access the singleton class in both applications.
How many objects of the singleton class will be created? I believe that the entire tomcat server runs on a single JVM instance, with all the web applications running on it.
In Java, it is difficult or impossible to create a singleton that applies to the whole JVM. Usually, singletons are implemented using "static". But "static" means "one copy per ClassLoader".
In a simple Java program, there's only one ClassLoader, so you get one copy. In complex applications there are often several ClassLoaders, and you can then end up with more than one copy, if the same class is loaded by several ClassLoaders.
In a Web application server like Tomcat, this is often a good thing. Each Web application is better isolated from others, which is usually what you want.
However, because of the above potential confusion and other reasons, Singleton is not well-liked by many people. Use it only when you really have to. And read up on the alternatives. [ October 22, 2007: Message edited by: Peter Chase ]
Betty Rubble? Well, I would go with Betty... but I'd be thinking of Wilma.
Each web application will get a separate classloader, and classes loaded by two different classloaders are considered different classes even if they come from the same jar file. This means that your singleton class can have a different instance for each different classloader that loads it. Your Tomcat web apps will each get their own copy of the "singleton" - there will be two instances.
Ordinarily this is a good thing - you normally don't want two different web apps to affect each other. However, if you need to enforce singletonhood across the whole JVM, there are other options. Probably the easiest when using Tomcat is to put the singleton class in a jar file in $CATALINA_BASE/shared/lib. This area is used for code which is common to all web apps, and the code here is loaded by a different class loader, the shared class loader, which is the parent to all the application class loaders. This means that whenever you try to load a shared class using an application class loader, it will first ask its parent loader, which will ask its parent, recursively, up to the root loader. If any ancestor loader can load the class, that's the loader that will be used. So two different applications loading a shared class will both get the same class from the same shared classloader. And a singleton class will in fact be a singleton across the whole JVM.
For more info on Tomcat's various class loaders, see here.