When to use Singleton Pattern

[Sandeep Lodhia]

Hi,
In any application, can I make all Child DAOs class as singleton.All these children will extend Base DAO which will manage connections.
In the same way, can classes that serve purpose of service be made singleton.
My basic doubt is....in singleton pattern, how multiple requests are handled ?
If 2 requests try to access a singleton class simultaneously, how are they processed as there is only 1 instance of the class?
Thanks.
Sandeep

[Lasse Koskela]

It depends on whether the method you're accessing is synchronized or not. If it is synchronized, only one thread gets access to the method at a time. If not, the method better not use member variables for storing state as several threads are executing the code within the object...

[Ilja Preuss]

I really liked the description of the Singleton pattern in Kent Becks "Test Driven Development by Example". It goes something along the lines of:
How do you represent globals?
Don't. Instead try to think of an object oriented solution.
I couldn't agree more... (Of course I needed to use Singletons for a long time before I learned to mistrust them )

[Hung Tang]

yes..Adding to what Lasse had said, if you decide to make a class Singleton, you have better not have member variables declared for that class. If you do have member variables, be aware that there can be multiple threads accessing it at the same time.
Say if have a singleton class called Foo, and you have a newInstance() that looks like:

public Foo newInstance() {
  if (singletonInstance == null) {
    singletonInstance = new Foo();
  }
  return singleInstance;
}

now it is possible that two threads can call newInstance() at the sametime!! so you can potentially have two instances instantiated and that's no good, its no longer a singleton then.
To prevent this, you must synchronize the method.
once synchronized, you can be assured that no two instances are ever created in that method.
Now if you DO decide to have member variables that allows write privileges, be sure to synchronize access to them. Usually this a pain because you will have to keep track everywhere in your application that can potentially access these member variables, so you will have to learn some defensive programming otherwise you can run into problems in running multi-threaded applications. However, if you design your objects as immutable, you can safely ignore this whole synchonizing, threading issues since you can't possibly write to these member instance variables, so there's no need to synchronize access to them.