Singleton is a design pattern means allowing only one instance of the class. (Check out more on singleton’s here) Singleton works well till the point you have single JVM.
In a multiple JVM’s environment, each of them will have their own copy of the singleton object which can lead to multiple issues specially in a clustered environment where the access to the resource needs to be restricted and synchronized.
To achieve clustering across JVM’s, one can use multiple techniques (JMS, DB, Custom API, 3rd party tools), but each of them have an impact on the business logic. If the requirement for JVM clustering is realized later in the game, then change to business logic will be huge.
- In case, the requirement to have singleton across JVM’s is realized later, then tools like Terracotta, Oracle Coherence are good options. These work on the concept of providing an in memory replication of objects across JVMs in effect providing you singleton view or making use of any of the cluster-aware cache provider’s like SwarmCache or JBoss TreeCache should work as cache entries are singletons and clustering is built in.
- Also, there is product called JGroups – which uses multi-cast comm. (TCP/UDP). It allows to form a group and Applications (JVM’s) can participate and JGroups will send messages to everyone in the group so that they can be in sync.
- Application server’s also provide some level of custom API’s to circumvent this problem.
- JBoss has HASingleton Service ( based on MBeans) which is meant to solve this problem. Check here and here
- Weblogic has the concept of Singleton Service – where only instance runs within the cluster and all clients will look up to the same instance.
- WebSphere supports the concept of singleton across cluster in the WebSphere XD version of the application server as the partition facility – ObjectGrid