Singleton class and instance methods

[Mohamed Farouk]

Dear Friends
I have a question If I create a singleton class with no state (I mean no instance attributes). But I have many instance methods in it with local variables and static attributes only. Can this object handle concurrent request from multiple threads at the same time. Will there be any impact on object interms of contention(threads waitin for this object). If I understand right unless a method or code block is synchronized in the code ed the jvm does not create locks or monitors.
Please help me as I am thinking of creating a DAO as singleton and just thinking of Contention/performance.
Regards
Farouk

[Stan James]

Many threads calling unsychronized methods on a singleton should be no worse than calling them on an instance per thread. You have identified the risks with instance variables. Having none is best in this case. You should synchronize access to static variables unless they are final or you are somehow comfortable that they will not change after initialization.

I'll leave the discussion of a singleton DAO for more thought.

[Edwin Dalorzo]

If your Singleton does not have any instance method it is a good sign that it is very probable that you may not need syncrhonization of your instance methods, because your class have nothing that can be modified concurrently by multiple threads.

However you must syncrhonize at least your getInstance() method to avoid two threads create an instance of your Singleton class simultaneously.

The contention issue is in function of how heavy the process of initializing the Singleton is. While the object is being initialized no other threads will be allowed to get the instance of your Singlenton.

Once the Singleton is initialized, contention should not be an issue, since the method will simply return the initilized instance of the class.

If such initialization process is heavy, maybe you can delay synchronization until it is absolutely necessary, that is to say, prior to instantiating your Singleton only instance variable. You can do this by means of using a synchronized block
[ May 11, 2006: Message edited by: Edwin Dalorzo ]

[Ken Blair]

Originally posted by Edwin Dalorzo:
However you must syncrhonize at least your getInstance() method to avoid two threads create an instance of your Singleton class simultaneously.

Instead it would be better to either use a static variable initializer or an intialization on demand holder. Synchronizing the method is probably the last approach I'd use, coming just before the fixed double-checked locking idiom.

[Edwin Dalorzo]

The static variable initializer approach implies that you initialize the Singlenton instance when the class is first loaded by the ClassLoader.

What if you need to pass some parameters to the class to initialize it? You cannot do that in the static initializer if you know the value of the parameters until the moment your first create the Singleton instance.

Another disadventage of static intializer has to do with the exception handling. Since the static intializer is executed by the JVM when the class is first loaded, there is no way to throw an exception from the initialization block, which you could better control with a getInstance method.

Intialization on demand seems to be based on a similiar approach as far as I can see, and conveys the same disadventages, since the instance, hold by the SingletonHolder implies a simple initialization using a single operation, and the instance is first crated when the class is loaded by the JVM. It only visible adventage is that it lazily initialize the Singleton, but it is not intented as an alternative for synchronization in the case where the Singleton is a complex object whose initilization requires more than a Single line of code and where exceptions may happen.

public class Singleton {
 
    private Singleton() {}
 
    public static Singleton getInstance() {
        return SingletonHolder.instance;
    }
 
    private static class SingletonHolder {
           private static Singleton instance = new Singleton();
    }
}

On the other hand, the double check locking idiom is not implicit in the syncrhonization of the getIntance method, not even if you use a synchronized block. It happens when you read the value of the instance variable out of the syncrhonied block to control the execution of the synchronized block. If anoter thead had read the variable a nanosecond before, than two threads may enter the synchronized block and intialized the object twice.

Ken, why do you suggest this is implicit in a synchronized getInstance method?

For instance:

private static Question11 instance;
 
public static Question11 getInstance(){
synchronized(Question11.class){
if (instance==null)
instance = new Question11();
}
return instance;
}

...should not be subject to the double-check locking bug.

Thanks in advance!
[ May 11, 2006: Message edited by: Edwin Dalorzo ]

[Ken Blair]

Originally posted by Edwin Dalorzo:
The static variable initializer approach implies that you initialize the Singlenton instance when the class is first loaded by the ClassLoader.

No, it implies that you initialize the instance when the class is initialized, which is not necessarily the same time it's loaded.

Originally posted by Edwin Dalorzo:
What if you need to pass some parameters to the class to initialize it? You cannot do that in the static initializer if you know the value of the parameters until the moment your first create the Singleton instance.

Use an initialization on demand holder.

Originally posted by Edwin Dalorzo:
Another disadventage of static intializer has to do with the exception handling. Since the static intializer is executed by the JVM when the class is first loaded, there is no way to throw an exception from the initialization block, which you could better control with a getInstance method.

First of all, I said a static variable initializer not a static initializer, they're not the same thing. Second, it would be executed when the class is initialized which is not necessarily the same time it is loaded. Third, I've never encountered a situation where I actually wanted getInstance() to throw an exception, but if you did I suppose that might be a good time to use it.

Originally posted by Edwin Dalorzo:
On the other hand, the double check locking idiom is not implicit in the syncrhonization of the getIntance method, not even if you use a synchronized block. It happens when you read the value of the instance variable out of the syncrhonied block to control the execution of the synchronized block. If anoter thead had read the variable a nanosecond before, than two threads may enter the synchronized block and intialized the object twice.

Ken, why do you suggest this is implicit in a synchronized getInstance method?

I didn't.

[Srinivas Kalvala]

Originally posted by Mohamed Farouk:
Dear Friends
I have a question If I create a singleton class with no state (I mean no instance attributes). But I have many instance methods in it with local variables and static attributes only. Can this object handle concurrent request from multiple threads at the same time. Will there be any impact on object interms of contention(threads waitin for this object). If I understand right unless a method or code block is synchronized in the code ed the jvm does not create locks or monitors.
Please help me as I am thinking of creating a DAO as singleton and just thinking of Contention/performance.
Regards
Farouk

Hi

First see, Creating a class as Singleton for DAO is not recommended, as every call from the frontend has to converge here even in a distributed platform.

Before the solution for your problem, please rethink of your design.

[Mohamed Farouk]

Thanks for all your replies
Regarding the last recommendation about not using Singleton as DAO because all the threads are converging?

I do not see a problem if all threads are converging into the class in the DB layer which is a singleton with no instance attributes. Please can you explain what is the problem with distributed tier and all front end converging on front end

Thanks
Farouk

[Stan James]

As long as nothing is synchronized I wouldn't worry about it being a bottleneck.

Do you use conventional connection pooling behind your DAO? That's the next "shared resource" point that would be really interesting.

Bear in mind that the Singleton pattern in the GoF book allows a small, controlled number of instances, not necessarily exactly one. Any chance you might wind up with an instance per datasource some day?