I will discuss here how singleton instance works across JVM, server (for example, Tomcat, WebSphere) and clustered environments. The acronym JVM stands for Java Virtual Machine. Singleton instance generally created from singleton design pattern. The purpose of the singleton design pattern is to create a single instance from a class per application per JVM. So there is only one instance is available for a class per application per JVM.
You may be interested to know why singleton design pattern is required.
In the next subsequent sections I will discuss how singleton instance behaves across JVM and servers, such as, Tomcat, WebSphere and clustered environments.
Singleton Instance across JVM
As I have already specified earlier in this tutorial that a single instance is created per JVM per application from a singleton class, so for each JVM there will be a separate instance from singleton class. This will be more clear in the subsequent sections.
Singleton Instance in Tomcat server
If you have a web application where you have a singleton class and if you are running two instances (two separate war files deployed) of a web application into Tomcat server then two different instances from the singleton class will be created in JVM running the Tomcat server. This is because the singleton class is stored in each separate web application (war file).
But if your web application (war files) uses a singleton class from JRE or Tomcat shared library then web application will get the same instance of the singleton class. In this case single instance will be used for multiple instances of the same web application (war files).
This happens due to the fact that the Tomcat server uses individual class loaders for web applications. When a web application class loader needs a class, it tries to find it in the class path (a path to the class or collection of classes) and if it cannot find the required class then it asks its parent class loader to find the required class.
Singleton instance in WebSphere server
IBM WebSphere application server gives you options regarding how you want to use singleton instance in your application.
If singleton class is loaded as part of EAR application then the singleton class is available to the application only.
So if you have multiple EARs, then for each EAR there will be completely separate independent instance for the singleton class associated with each EAR application.
Now there is another option available in the IBM WebSphere application server – a checkbox labeled with text
Use an isolated class loader for this shared library.
So if you check the checkbox labeled with the above text, then it is available as a singleton to any application which links to this shared library. In this case singleton class will be loaded by an isolated class loader and each respective application will point to the same singleton instance.
If you uncheck the checkbox then it is available as a singleton to any application which links to the shared library. In this case singleton will be loaded as part of the application and each application will have its own separate singleton instance.
If the shared library is associated to the server then the singleton will be loaded as part of the server. In this case the only one singleton will be available to all applicationa running on the server.
Singleton instance in clustered environment
Singleton instance in clustered environment can be managed using Java RMI, distributed cache and vendor products.
More information on singleton instance across clustered environment, you can find at singleton instance in clustered environment.
That’s all about single instance across JVM.