A Singleton says that it will have one instance per JVM. In multi nodes cluster environment, we will have multiple instances of application running on those nodes. So, if we have singleton objects in the application, then, won't it break the singleton pattern? Does it mean we should not have any singleton object in multi node clusters?
People are generally Singletons because each of us is unique. However, if you were somehow cloned so that there's more than one of you running around wherever that may be, then doesn't that automatically make you non-unique? By the same token, you could argue that having the same kind of object in multiple nodes by definition makes it a non-Singleton.
The best ideas are the crazy ones. If you have a crazy idea and it works, it's really valuable.—Kent Beck
Junilu is being kind when he says "these approaches brings its own set of challenges", I would go right out and say it's hard as f**k.
For some years I worked on the Matching Engine for a large financial trading platform and in this system the 'singleton' was the active order book that had to be kept synchronised across a primary and live backup server. It was difficult, like really difficult, and enormous amounts of effort went into making it work reliably.
Distributed applications are hard. If possible, can you design the application in a way so that it doesn't require singletons? For example, if you're using a system that communicates to a database, make all of your database operations atomic so that it doesn't need to be a singleton. Or have a coordinator/worker architecture where the coordinator handles the work that needs to be synchronized, and delegates certain parts of work out to the worker nodes to speed things up.
Flat-out forget Singletons. The only time Singleton classes work is if the JVM is also a Singleton. Otherwise, it's like Junilu - an instance of earth.inhabitants.People.
When running a cluster operation, other methods are required to ensure central state maintenance. For persistent data (databases), that's almost always done via transactions. In effect, then the "singleton" becomes a lock in the shared database. And if the database itself is part of the cluster, it's up to the database itself to maintain state integrity across all of its instances. Which, if properly configured, it will do, although there's a performance penalty and/or latency concerns.
For long-term synchronization, you can have a lock object in a shared resource, but again, there's a cost involved. The popular JVMs have no built-in cross-VM state synchronization though, so you'd have to code it into the apps.
"privilege" comes from the Latin words for "private" and "law" (legal) and dates to feudal times. To "claim privilege" meant that you were above the laws that applied to the common people.