• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Ron McLeod
  • Rob Spoor
  • Tim Cooke
  • Junilu Lacar
Sheriffs:
  • Henry Wong
  • Liutauras Vilda
  • Jeanne Boyarsky
Saloon Keepers:
  • Jesse Silverman
  • Tim Holloway
  • Stephan van Hulst
  • Tim Moores
  • Carey Brown
Bartenders:
  • Al Hobbs
  • Mikalai Zaikin
  • Piet Souris

Singleton Pattern for Performance Gains

 
Greenhorn
Posts: 7
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
In a multithreaded environment, do classes that hold no state (has no member variables) better off implemented as singletons (except for some exceptions)?
For example, if I have a business object with the following method signatures and without having any member variables:
public final class MyUserBusinessObject {
public UserValueObject authenticate(String username, String password) {
//authentication logic here
}
public UserValueObject register(UserValueObject userDetails) {
//registration logic here
}
//etc...
}
... is this a good candidate for becoming a singleton? Every user does not need his/her own copy of this object as it holds no state anyway and threads can access the methods concurrently.
Finally, bringing it a step further, is it also OK to implement the DAO layer (accessing a DB via JDBC) as a singleton if it, once again, does not hold any state?
In terms of performance, instantiating a new object everytime for the class will be a performance hit(?) if, say, 20000 instances are created for very big sites.

Happy Holidays!
 
author
Posts: 11962
5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Object creation is rarely a performance bottleneck. Yes, sometimes it is (e.g. related to string concatenation) but most often not. I would stress good OO design over such premature optimizations (which are the root of all evil, by the way ).
 
Sheriff
Posts: 6920
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
If your object holds no state it's not really an object, it's just a collection of unrelated methods. using a Singleton would make no sense here either.
If you really want to do this, all you need to do is make your methods "static". Then you never need to instantiate an object at all:

Then you can access any of these methods simply using something like.
UserValueObject user = MyUserBusinessMethods.authenticate("frank", "javaranch");
However the existance of methods like this is often a "code smell" indicating that something is wrong with your design. I'm particularly worried about how this "authenticate" method knows where to look for the user and pasword data to check the supplied values against, for example. You haven't passed that information in to the enclosing object (via a constructor, "init" method or "setter"), and you don't tell it in the
method parameters.
Do you really plan to hard-code the database connection details and query string (or whatever) in that method itself? If so you are in grave danger of making an effectively untestable application!
You write: Finally, bringing it a step further, is it also OK to implement the DAO layer (accessing a DB via JDBC) as a singleton if it, once again, does not hold any state?
But surely such a DAO does hold state! It holds the details of which database to contact, probably a reference to a connection pool, maybe a logging level or debug flag. What prompts you to think of it as being stateless?
In terms of performance, instantiating a new object everytime for the class will be a performance hit(?) if, say, 20000 instances are created for very big sites.
Sure. But (a) probably not as much of a performance hit as you might expect, especially when compared with things like pooling or not pooling database connections, and (b) even so the solution is not to splatter an application with Singletons making it virtually impossible to test or to extend and improve later.
 
Yves Sy
Greenhorn
Posts: 7
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thanks for the replies.
>Do you really plan to hard-code the database connection details and query >string (or whatever) in that method itself? If so you are in grave danger >of making an effectively untestable application!
>...
>But surely such a DAO does hold state! It holds the details of which >database to contact, probably a reference to a connection pool, maybe a >logging level or debug flag. What prompts you to think of it as being >stateless?

Of course it will not be hardcoded and neither did I say that I planned to do so. A connection manager can be used and called within the method:
public class RdbmsUserDAO implements UserDAO {

public UserValueObject authenticate(String username, String password)
throws DAOException {
Connection con = ConnectionManager.getInstance().getConnection();
// etc.
}
}
Details such as connection pooling and database connection details are handled by the ConnectionManager and maybe loaded thru XML or a properties file on startup.
So basically the bottomline is that having many singletons will make it "bad design" for the application and reduces its flexibility and maintainability, but in this case, possible?
 
Frank Carver
Sheriff
Posts: 6920
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Of course it will not be hardcoded and neither did I say that I planned to do so. A connection manager can be used and called within the method:
...
Connection con = ConnectionManager.getInstance().getConnection();
Ah. You plan to use a Singleton for this, too.
So although you are not hardcoding the actual implementation of the connection code, you are hardcoding the name of the class which does it.
For testing puposes that's effectively the same thing. In neither case can you substitute a "dummy" or "mock" connection pool for testing .
What if you were to pass in the connection manager instance when your utility class is created?

That way when you wish to test the operation of your methods you can simply create a MyUserBusinessObject passing in a mock connection manager;
Please, always think at least two or three times and consider all the alternatives before jumping to the conclusion that a Singleton is ever the right answer.
 
Yves Sy
Greenhorn
Posts: 7
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thanks for the input. That seems like a better way to do it
[ January 02, 2004: Message edited by: Yves Sy ]
 
Ranch Hand
Posts: 862
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I like to hide the fact that I am using a singleton as an implementation detail. That way if you decide later using a singleton is not appropriate (maybe you add state to the object) then you can change it without breaking code.
 
Lasse Koskela
author
Posts: 11962
5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I believe Steve meant
 
You have to be odd to be #1 - Seuss. An odd little ad:
Thread Boost feature
https://coderanch.com/t/674455/Thread-Boost-feature
reply
    Bookmark Topic Watch Topic
  • New Topic