Originally posted by sajjad ahmad:
commandRegistary.getCommandInfo(�Login�)
This will give me a commandInfo object from which I know that which class I have to dynamically load for this particular command (and set it�s attributes I got from client).
The main point in the above story is, I am using a singleton class for this purpose and wondering weather I should stick with this approach or create a pool of instatnces of this class and then use those instances in my application?.
If your commandInfo object is stateless (it doesn't hold any values that the program changes while it uses the object), then it makes no sense to create a pool with multiple instances of the object. The objects would all be exactly the same, and there is no advantage in any way to use multiple instances.
It might be good for performance to create a pool if the objects do have state and are heavy-weight (i.e. if it takes a relatively long time to create and initialise a new object).
Tomcat for example recycles Request objects in a pool: it has a pool of Request objects, and if an HTTP request is received it takes an object out of the pool, fills in the data of the HTTP request and passes it to the appropriate
servlet. When the servlet is done, Tomcat puts the Request object back in the pool. Note that the Request object holds values while the servlet is using it - it's not a stateless object.
For lightweight objects (objects that can be created relatively quickly) it isn't worth it to pool them, because creating and garbage collecting such objects is usually faster than managing them in a pool. (
Java's garbage collector has special optimizations to quickly clean up short-lived objects).