• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Singleton in multiple nodes cluster?

 
Ranch Hand
Posts: 441
2
Java
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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?
 
Sheriff
Posts: 17644
300
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Likes 2
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Junilu Lacar
Sheriff
Posts: 17644
300
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Likes 3
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
There are at least two ways to deal with the situation you describe:

1. Have a true Singleton that is shared across multiple nodes.
2. Make changes to any one instance propagate to all other instances.

Each of these approaches brings its own set of challenges around synchronization, consistency, performance, just to name a few considerations.
 
Sheriff
Posts: 5555
326
IntelliJ IDE Python Java Linux
  • Likes 2
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Bartender
Posts: 242
27
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Saloon Keeper
Posts: 27762
196
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
reply
    Bookmark Topic Watch Topic
  • New Topic