singleton - To be or not to be ?

[nalaka]

I am new to Spring. I have gone through reference materials and sample applications and it says default behavior for bean is singleton. In real world java applications I have seen only a handful of singleton classes. Then why Spring applications promote Singleton. The documentation says if the bean is non-singleton, framework will not handle life cycle. In a typical application say struts base web application which (action class, java beans containing business logic, utility classes (say math)), which are candidate for singletons? I am very impresses with Spring so far, but equally confuse with the term Singleton
Thanks in advance

www.virtusa.com

[Costin Leau]

This thread might shed some light then: http://forum.springframework.org/showthread.php?t=25763

[nalaka]

This thread might shed some light then: http://forum.springframework.org/showthread.php?t=25763

Thanks for the reply.. I already went through that thread.. Still I am bit confusing. The spring documentation says;

Beans are deployed in singleton mode by default, unless you specify otherwise. Keep in mind that by changing the type to non-singleton (prototype), each request for a bean will result in a newly created bean and this might not be what you actually want. So only change the mode to prototype when absolutely necessary.

This shows spring favors singleton a lot. My question is while, in real world java applications, singletons are rear, why Spring promoting singletons? :o Is it because most of the beans that containing business logic (of course state) are not going to be handled directly by spring, rather spring framework to be used in singleton favoring contexts like database connection, integration with E mail, etc ?

[Costin Leau]

In their original form, singletons are a problem since you can't change their lifecycle afterwards without modifying a lot of code.
For example you start with a stateless class which can have a shared instance since it doesn't hold any state. However, later on you add some state to it but then you can't share the instance anymore.
Spring container offers you a very nice solution since the lifecycle already built in and you don't have to care about it. Basically you can move between a shared instance to prototype or custom scoping without any code change.
Stateless design is very efficient in term of performance and scalability - if you can share an instance do it.
I guess most people associate the singleton term with the original implementation which again, is not recommended.

[benethridge]

I guess most people associate the singleton term with the original implementation which again, is not recommended.

Nalaka, maybe this will help: Do you understand what Costin means by "original implementation"? If I'm understanding him (and the Spring team), Spring does not create singletons in the usual sense of the word (i.e. as per the original Gang-of-4 pattern, i.e. as per the "original implementation"). Spring "singletons" are what the Spring team is calling "Per-ApplicationContext singletons". Understanding the meaning and consequences of that term (which I did not a few days ago) is a vital part of understanding Spring, IMHO. Perhaps someone on the Spring team can explain that better, if you need it.

Ben

[nalaka]

Spring container offers you a very nice solution since the lifecycle already built in and you don't have to care about it. Basically you can move between a shared instance to prototype or custom scoping without any code change.
Stateless design is very efficient in term of performance and scalability - if you can share an instance do it.
I guess most people associate the singleton term with the original implementation which again, is not recommended.

I highly appreciate all your comets..
Does this mean if my bean contain state information (instance variables), still I can safely declare it as a singleton, when manged within spring framework?
For example consider following class;

public class Class1 {
private String userId;
public String getUserId() {
return userId;
}
public void setUserId(String string) {
userId = string;
}
}

If I use this within spring context with default behaviour (singleton=true), If one of the client of this bean call the setUserId() and change the state of userId. Then if the next client call the getUserId(), is it going to get the modified state of previous client? (this is not my intention anyway). So in this type of scenario do I have to made this bean prototype?
I would like if anyone explain "Per-ApplicationContext singletons" in the light of my bean example above.
Can anyone provide me with a simple rule (rule of thumb) , that guide whether my bean is a candidate to be declared as a singleton or otherwise.
Thanks in advance.

[Costin Leau]

Consider that you have a bean definition for your Class1, named "A" defined as a singleton. On every request to the application context, the same instance of A will be returned (i.e. the same object). If you change it's state (i.e. somebody modifies the userId), the everybody else who holds a reference to "A" bean will see this change.
So the singleton doesn't apply here since, your bean is stateful - here you're better off with prototype (the opposite of singleton) which means that every time you ask the "A" bean from context, you'll get a fresh new instance (a new object).
This way, the changes won't propagate since they are made on different objects.