singleton query

will singleton work in a clustered environment ?
what would you need to do to make it work ?

In double checked locking we have the following ::

first Check for null
symchornized block
second check for null

why is the second check for null reqd ?

First check is understood where you dont want every thred unnecessarily to incurr a lock
by sinply checking for null - you can decide
so lock is incurred only the first time

not understood why the second time a lock is reqd ?

Thanks
~satish

http://faq.javaranch.com/Search?search_words=distributed+singleton&match_all=yes&search_in=ALL&search_forum=9&sort_by=DATE&search_date=ALL&search_member=&search_topics=ALL&submit=Search

http://faq.javaranch.com/Search?search_words=double+checked+locking&match_all=yes&search_in=ALL&search_forum=27&sort_by=DATE&search_date=ALL&search_member=&search_topics=ALL&submit=Search

Thanks Ilja.
I was guilty of not searching and taking some effort before asking !

After doing the searches and the necessary read here is what I understand ::

1 >Singletons across clusters
Rarely is their a need to maintain a single Object across all JVM's
since if this was needed we would need to serialize / send across the n/w which in itself is a performance issue

In many cases having one object per JVM is good enough

So next time some interviewer is going to ask me such a question - I am going to throw the kitchen sink at him !

2 >Why do I need the second null check in synchronised block ? ( double checked locking )

This is to prevent the second thread that has already passed the first non synchronised null check from instantiating a second instance .

Thanks ,
~satish

You're welcome.

Note that double checked locking actually didn't work reliably before Java 5.

Originally posted by Ilja Preuss:
You're welcome.

Note that double checked locking actually didn't work reliably before Java 5.

Which is why double checked locking was always regarded as an anti-pattern. Still, even with the changes made to the Java Memory Model post Java 5.0, which allows double checked locking to work reliably, there are other -clearer- alternatives. Firstly, if lazy initialization doesn't offer an obvious performance gain for the singleton class, keep things simple and use eager initialization. If you absolutely must implement a lazy initialization mechanism, you may want to favour a lazy initialization holder approach over double checked locking, because the code involved is much more comprehensible.

Jelle, well said!

The benefit of having read Java Concurrency in Practice, I must admit