singleton - To be or not to be ?

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 :cool: so far, but equally confuse with the term Singleton :eek:
Thanks in advance

www.virtusa.com

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

Quote:

---

Originally Posted by Costin Leau

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;

Quote:

---

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 ?

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.

Quote:

---

Originally Posted by Costin Leau

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

Quote:

---

Originally Posted by Costin Leau

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.

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.

Quote:

---

Originally Posted by 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.

---

Now I am clear.. thanks all for replies..:)

Quote:

---

Originally Posted by 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.

---

Correct me if I'm wrong, but there is a subtlety in the above statement, that may still not be clear to everyone:

(a) "the application context" - has to be the SAME INSTANCE, i.e. you have to "pass around" the application context object reference to get at the "A" as a singleton. If you create a new application context object, "A" will NOT behave as a singleton, even though it's coded that way in the spring xml config file.

(b) "everybody else" can't be in another jvm or even another thread of execution (normally). "everybody else" would normally mean every other object in the current thread that has a reference to the application context object, or can get at it somehow (via, say custom ThreadLocal logic)

Put all the above together and I think you could build a definition for "per-ApplicationContext singleton". Again, please correct me if I'm not understanding this correctly, as this one is vital to basic Spring understanding, and I'm no expert at it yet.

Ben

I think the concept is *sometimes* overly complicated. Here is my simple view, Spring offers a sophisticated bean factory object. This factory can also cache the objects it creates. These cached objects are called singleton objects in the Spring vernacular. From this simple view, all the other consequences follow, such as these singletons are per factory object only, per classloader, etc.