Best Method for the Singleton Design Pattern

[sakthi moorthy]

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

   

package org.hibernate.UTILS;

import org.hibernate.cfg.Configuration;
import org.hibernate.HibernateException;
import org.hibernate.SessionFactory;


public class HibernateUtils 
{
      private HibernateUtils()
      {

      }
     
	private static SessionFactory seesionFactory = null;
	
	private static final SessionFactory makeSessionFactory()
	{
		try {
                      if (sessionFactory==null)
			seesionFactory = new Configuration().configure().buildSessionFactory();
		} catch (HibernateException e) {
			// TODO Auto-generated catch block
			e.printStackTrace();
		}
	  return seesionFactory;	
	}
	
	public static SessionFactory getSessionFactory()
	{
	   return 	makeSessionFactory();
	}
	
	
}

 

SingleTon Design Patern Program 2

   
package org.hibernate.utils;

import org.hibernate.SessionFactory;
import org.hibernate.cfg.Configuration;


public class HibernateUtils 
{

    private HibernateUtils()
      {

      }

    private static SessionFactory sess = null;
    
    public static synchronized final SessionFactory getSessionFactory()
    {
    	if(sess==null)
    		sess = new Configuration().configure().buildSessionFactory();
    	 
    	return sess;
    }
    

}



 

[Miklos Szeles]

Your first implementation is not thread-safe, so I think you should go with the second. Or I often saw the following:

public static final SessionFactory getSessionFactory()  
    {  
        if ( sess == null )  {
        	synchronized (SessionFactory.class) {
				if (sess == null)
		            sess = new Configuration().configure().buildSessionFactory();
			}
        }
        return sess;  
    } 

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]

Hey,

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

    // static factory for creating Session objects.
    private static final SessionFactory SESSION_FACTORY;

    // static initialisation block
    static {
        try {
            // Create the SessionFactory from hibernate.cfg.xml
            SESSION_FACTORY = new Configuration().configure().buildSessionFactory();
        } catch (Throwable ex) {
            // Make sure you log the exception, as it might be swallowed
            if (LOG.isDebugEnabled()) {
                LOG.debug("Failure while initialising: " + ex);
            }
            throw new ExceptionInInitializerError(ex);
        }
    }

[Campbell Ritchie]

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]

Miklos Szeles wrote:

public static final SessionFactory getSessionFactory()  
    {  
        if ( sess == null )  {
        	synchronized (SessionFactory.class) {
				if (sess == null)
		            sess = new Configuration().configure().buildSessionFactory();
			}
        }
        return sess;  
    } 

see Double-checked locking here why it should not be used

[Miklos Szeles]

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]

/**
 * Class with lots of spelling errors, which is final to prevent extension, and doesn't implement
 * Serializable
 */
public final class FooSingelton
{
    private static final FooSingleton instance = new FooSingelton();

    private FooSingelton()
    {
       /* Some sort of code would go in here */
    }

    public static FooSingelton getInstance()
    {
        return instance;
    }

    public void doSomething(Foo f)
    {
       /* Some sort of code would go in here */
    }
}

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]

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.

   
public class FieldType {
    
    private FieldType() { ... }

    private static class FieldHolder
    {
         private static final FieldType field = new FieldType();
    }

    public static FieldType getInstance()
    {
        return FieldHolder.field;
    }
} 

[Miklos Szeles]

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]

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]

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