I am stuck to make a decision of using non-static vs static methods in a singleton class.
I have a DAO which is a singleton class, I have some insert methods in this DAO which are non static. Each method contains respective logic of creation of Connection and calling of a respective insert stored-proc on the Database end and closing of the connection after successful/failure of insertion.
What would be my take of declaring these methods static? Will declaring these methods static would improve on the performance end?
I have done Load testing on this DAO and everything works fine.
There is little difference in execution time as far as static versus non-static methods goes.
I would make the methods non-static because they are acting on an instance of the class. If you changed the class away from the one-instance singleton pattern, those methods wouldn't have to change.
Why are you making this class a singleton anyway? What goes logically wrong if it is not a Singleton?
There is no emoticon for what I am feeling!
Joined: May 31, 2002
I have some constant code to go in the instantiation block, reading some of the properties etc., and I followed the Singleton pattern as it is practise in my current work place. I am not having enough documentation to support why I have declared methods as non-static. Will declaration of methods non-static result in erroneous implementation at high loads of incoming requests.
I would be glad if we could find any documentation related.
Joined: Sep 16, 2005
Hmmm... I don't know if "it is practise in my current work place" is a reason, or the absence of a reason. In any case, are you asking about synchronization? Does your instance or the class itself hold some state that requires synchronization? I'm asking because your reference to high load of incoming requests seems to be implying something that you have not been clear about so far.
Joined: May 31, 2002
The intention of the Singleton is ..mainly reading of properties and instantiation of some constants. Yes I am worried about the Synchronization at high Loads.
Again, one typically creates Singletosn when it is a logical error to create extra copies, for example in an enumerated type where == is used to compare objects.
If what your class "many" does is read properties and initialize constants, whether or not it's a Singleton, those tasks sound like they will be only done once... [ December 13, 2005: Message edited by: Jeff Albrechtsen ]