• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Best Method for the Singleton Design Pattern

 
sakthi moorthy
Ranch Hand
Posts: 54
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Which Coding will you choose for the singleton design pattern and why or what are the advantages or disadvantages of the following two coding....

Single Ton Program 1




SingleTon Design Patern Program 2

 
Miklos Szeles
Ranch Hand
Posts: 142
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Your first implementation is not thread-safe, so I think you should go with the second. Or I often saw the following:



I think it is a little bit more efficient since you lock only at the first call.
About cathching or propagating the HibernateException I can't say anything, since I don't know too much about Hibernate.
 
Sean Clark
Rancher
Posts: 377
Android Java Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hey,

This is what I have always used and I think this is how it is documented in the hibernate forum.

 
Campbell Ritchie
Sheriff
Pie
Posts: 50180
79
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Probably too difficult a question for "beginning Java". Moving.

What is wrong with having a private static final instance of the class, instantiating it at class loading time, and using a private constructor? That avoids what Miklos Szeles quoted, viz double-checked locking. I have been told this does actually work using the new memory model in Java5, but was unreliable on older versions.
 
Muhammad Khojaye
Ranch Hand
Posts: 449
IntelliJ IDE Java Scala
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Miklos Szeles wrote:


see Double-checked locking here why it should not be used
 
Miklos Szeles
Ranch Hand
Posts: 142
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks for pointing me to that description Muhammad. I missed the volatile(my fault) but I wasn't aware of that this implementation is not correct on JVM 1.4(or less). So to summarize the answers:
If it is possible, we should create the object in a static initializator.
If we need lazy initialization for some reason and we are developing for JVM 1.5 or higher, we should use dobule-checked locking and under JVM 1.5 we should simply synchronze the getter method.
Is this correct?
 
Campbell Ritchie
Sheriff
Pie
Posts: 50180
79
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
That's one way to do it. See Effective Java by Joshua Bloch, 2nd edition pages 17ff for more details. He quotes two other ways to do it.
 
Muhammad Khojaye
Ranch Hand
Posts: 449
IntelliJ IDE Java Scala
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Miklos Szeles wrote:If we need lazy initialization for some reason and we are developing for JVM 1.5 or higher, we should use dobule-checked locking and under JVM 1.5 we should simply synchronze the getter method.
Is this correct?

use the lazy initialization holder class idiom as define in Effective Java.

 
Miklos Szeles
Ranch Hand
Posts: 142
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Even if it wasn't me who started the thread, thanks guys for the valuable information. I think my next Java book will be Effective Java
 
Campbell Ritchie
Sheriff
Pie
Posts: 50180
79
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Miklos Szeles wrote:I think my next Java book will be Effective Java
Excellent book Another book worth reading is "Java Puzzlers" by Bloch and Gafter.

And you're Welcome.
 
Muhammad Khojaye
Ranch Hand
Posts: 449
IntelliJ IDE Java Scala
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Miklos Szeles wrote:I think my next Java book will be Effective Java

Yes and I would also recommend The Collections Framework.
and You are always welcome
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic