• 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
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

When we should pool resources?

 
Ranch Hand
Posts: 78
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi All!

In my application I have all the configuration of my command objects in an xml file, on application startup I have a singleton class which reads data from the xml file and creates a command registry (hash table) which now contains information about each command, i.e name of a command, any helper classes needed to execute that command etc.

Next time when I have to execute a command (coming from a client) I get the Command info from the command registry; have to usually execute a query on command registry e.g.

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?.

Feeling embarrassed to tell you that I can�t figure out the situations where I should use resource pooling and where I should avoid pooling resources.
Yes I know about Connection/Thread pooling infect have been using those techniques but in the current case cant figure out should or shouldn�t I use resource pooling here.
 
(instanceof Sidekick)
Posts: 8791
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Overall, this is something I generally like. A singleton factory is not a bad thing. A factory class with static methods and a static map would be another choice. Be aware that statics have one instance per class loader so there could be more than one copy of this stuff in memory, but that's probably not fatal.

Singletons and static methods both present challenges when you'd like to provide alternate implementations or extend one of them, perhaps mocks or dummies for testing. Those things are not impossible, but likely more difficult.
 
Java Cowboy
Posts: 16084
88
Android Scala IntelliJ IDE Spring Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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).
 
Consider Paul's rocket mass heater.
reply
    Bookmark Topic Watch Topic
  • New Topic