Win a copy of Building Blockchain Apps this week in the Cloud/Virtualization 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 ...
  • Campbell Ritchie
  • Paul Clapham
  • Liutauras Vilda
  • Knute Snortum
  • Bear Bibeault
  • Devaka Cooray
  • Jeanne Boyarsky
  • Junilu Lacar
Saloon Keepers:
  • Ron McLeod
  • Stephan van Hulst
  • Tim Moores
  • Carey Brown
  • salvin francis
  • Tim Holloway
  • Piet Souris
  • Frits Walraven

Spring and Singleton patteren

Ranch Hand
Posts: 244
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi All,

I have a question regarding Singleton pattern in my mind.
It is generally told not to use Singleton pattern in distributed architecture. Because it may be one per JVM, one per classloader etc. So the singleton nature is destroyed.

But a popular framework like Spring is using Singleton as its default scope. So how is it managing the Singleton nature of a class around the application in a distributed environment?
Can somebody explain me?
Posts: 436
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Singleton as a concept is not a problem. It is just a "one object of this class" idiom. That happens quite often... in fact so often that it is the standard scope for Spring.

What is bad is implementing it at language level (e.g. a constant holding an instance) because then you loose testibility, possibility to inject, it is hard to refactor and so on. All what is bad about the Singleton.

This is not true when managed by Spring. If you need another instance you just create it. Singleton in Spring does not enforce only one object of a class. It just means that the instance created is shared (and not like with the prototype scope every caller gets a new object).

When done at the language level this means you need to e.g. create a new constant, rewrite access, change dependent objects, think about thread safety...

So having "just one object of a class" is not a problem. Enforcing it on low-level is.
Grow your own food... or this tiny ad:
Java file APIs (DOC, XLS, PDF, and many more)
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!