Win a copy of Zero to AI - A non-technical, hype-free guide to prospering in the AI era this week in the Artificial Intelligence and Machine Learning forum!
  • 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 all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Liutauras Vilda
  • Paul Clapham
  • Bear Bibeault
  • Jeanne Boyarsky
Sheriffs:
  • Ron McLeod
  • Tim Cooke
  • Devaka Cooray
Saloon Keepers:
  • Tim Moores
  • Tim Holloway
  • Jj Roberts
  • Stephan van Hulst
  • Carey Brown
Bartenders:
  • salvin francis
  • Scott Selikoff
  • fred rosenberger

Singleton in multiple nodes cluster?

 
Ranch Hand
Posts: 431
2
Java
  • Likes 1
  • Mark post as helpful
  • send pies
  • 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: 15929
265
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Likes 2
  • Mark post as helpful
  • send pies
  • 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: 15929
265
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Likes 3
  • Mark post as helpful
  • send pies
  • 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: 4889
317
IntelliJ IDE Python Java Linux
  • Likes 2
  • Mark post as helpful
  • send pies
  • 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.
 
Rancher
Posts: 214
16
  • Mark post as helpful
  • send pies
  • 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: 22646
153
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Mark post as helpful
  • send pies
  • 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.
 
Hot dog! An advertiser loves us THIS much:
the value of filler advertising in 2020
https://coderanch.com/t/730886/filler-advertising
reply
    Bookmark Topic Watch Topic
  • New Topic