• 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

Caching property values in server memory

 
Ranch Hand
Posts: 101
1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I have this scenario. I have two property files which will be used frequently from a web application. I do not want to perform repeated file read operations everytime i need to access the values in this property file. Is there some way in which i can cache these values in server?
I was thinking of writing a singleton class with a hashmap which gets loaded from the singleton's constructor. This hashmap will hold all the values from the property files.
Is this a good way to ensure caching? or are there any better standard methods available.
Please help
 
Saloon Keeper
Posts: 15484
363
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
No, using a singleton is bad news. Global state is evil.

You could do what you suggested, except don't make the class singleton. Just create an instance of it and pass it to the objects that need the configuration data.

Instead of creating such a class yourself, consider using java.util.Properties.
 
Stanley Walker
Ranch Hand
Posts: 101
1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thank you Stephan.
My main purpose is to reduce a second file reading from the same property file in case the class is accessed again. In case i do not make the class a singleton every access to this class would mean a file I/O operation, the overhead of which i want to avoid.
My main question is how do i keep once read values from a property file in a cache state so that subsequent access will not require a file read.
If we are talking about a web application , is there some configuration i can make on the server?
 
Ranch Hand
Posts: 66
VI Editor Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
You could do this without a Singleton. What you're talking about is a utility class and you could still have the properties read exactly once.. and that too only when the first time the properties is accessed. From then on, you could just check if it's already loaded, and if yes, you can retrieve it from memory.

If we're talking about a web application, you could do this with a Context Loader listener and make sure it gets loaded during server start up, so that you know you don't have to read from the file every time you want to get a property.
 
Stephan van Hulst
Saloon Keeper
Posts: 15484
363
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Prabaharan Gopalan wrote:[..]a utility class and you could still have the properties read exactly once.. and that too only when the first time the properties is accessed. From then on, you could just check if it's already loaded, and if yes, you can retrieve it from memory.



No, please don't do this. This is no better than a singleton. This solution also entails keeping global state around. Let me stress again that global state is EEEEVVVILLLLL.

What you want to do instead, is create an *object* that reads the properties file once upon construction, and saves the data in its instance fields. You can then pass this object around to as many parts of your program as you like, which can read data from the object without having to read it all over from the file again. It's the same solution as the singleton object proposed in the first post of this topic, except that it's not a singleton, but a normal instantiable class. Do NOT use static methods to retrieve program state information. Singletons by their nature require static methods to retrieve the singleton instance.
 
Prabaharan Gopalan
Ranch Hand
Posts: 66
VI Editor Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Stephan, I do agree that singleton is not good candidate for this scenario. But, correct me if i'm wrong here, things read from a property file are supposed to not change during the life time of the application. In which case, I wouldn't call it being in one state or another, rather, static throughout. If this is the case, I fail to see the problem in having a static method to access a static variable that gets loaded only once.

As to doing this with a new instance of the object - this is prone to accidental creation of objects which might end up loading the file more than once. And there is no way we can restrict a user from creating more instances of the object. If there is a way to avoid this and barring the usage of singleton, if there is another option, I'd like to know.

I've been doing this for some time now (that's the way it was explained to me) and if this is wrong, I'd like to know the right way to do it.
 
Stephan van Hulst
Saloon Keeper
Posts: 15484
363
  • Likes 2
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
You definitely should consider it program state, whether it appears constant or not. The reason is that it's not constant. After all, it's loaded from a file, which may change between program executions.

So why is this bad? Well, it makes programs much harder to test and debug. Since methods in your program now rely on global data, rather than input given to them explicitly, you can not test them thoroughly without changing the global data, which in turn may also affect other methods that rely on the same global data. You want different parts of your program to be as independent from each other as possible. This makes for reliable programs, that are also easy to understand and maintain.

This is a much greater benefit than what preventing the user from instantiating too many objects will give. After all, if the user finds that the program is too slow, they can find out easily that they're creating too many objects, because the program is easy to read.

Static methods should only have a place in utility classes, or in immutable value types. They are used by the program, and by themselves have no bearing at all on the current state of a program. For example, java.lang.Math is a great utility class that contains static methods. These methods have no side effects, and their return value is determined by their arguments only (with the exception of the random() method, but then the entire point of random() is that it's unpredictable). Integer is an immutable value type, and contains various static valueOf() methods. Again, these methods are great, because they have no side effects and their return values are determined by their arguments only, and not any global data.

Singletons have very limited uses. A good way to use them is for actions that the program doesn't really care about. These actions don't interfere with the normal execution, and provide additional support only. A good example is the java.util.logging.Logger class. Loggers are not important enough that you want to bother with passing them as method arguments all the time, but they are useful enough that you might want to use them all over the place. The reason why they can be put in the global state of the program, is because the program doesn't base its logic on them. The return values of methods are not affected by what Loggers you have lying around in the global namespace. They also don't change the side-effects of methods on program state.
 
Prabaharan Gopalan
Ranch Hand
Posts: 66
VI Editor Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I am still coming to terms with all of this. I was of the impression that you'd write a singleton when you want the state of the object to be maintained at one place so that you don't end up having multiple states. And people usually make the singleton thread safe so that they want the guarantee that there's really only one of them.

And of course, your explanation makes is sensible than mine, so I'm thinking whether all my singletons so far are justified. Is there any way to get more people to take a look at this thread because I'd like to hear more than one opinion. I'm not saying you're not right, but I'd like to hear what others are doing under these same conditions.
 
Stephan van Hulst
Saloon Keeper
Posts: 15484
363
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
But ask yourself, why would you even want to guarantee there's only one of them? If you let all methods operate on instances they're being passed, as opposed to instances they retrieve globally themselves, then you're putting the responsibility of ensuring that it's the correct instance with the calling method. This is good, because when your program messes up, all the methods can say: "sorry guys, I just did what I'm supposed to do on the stuff that you gave me. If you didn't want me to work on that, then you should have given me something else". With a Singleton, it could have gone wrong anywhere, because all methods have access to your (possibly important) data, even methods that should not even have any business working with the singleton (consider evil code that is actually out there to mess up your data).

The nice thing about having to pass all the data explicitly (this is called dependency injection), is that when a method is acting strangely, you can substitute a dummy implementation for the real instance, to test the method without affecting the rest of the program.

Do a search on these forums (and Google) for "Singleton is evil" and "Dependency injection".
 
Stephan van Hulst
Saloon Keeper
Posts: 15484
363
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
This is also an interesting read: http://c2.com/cgi/wiki?GlobalVariablesAreBad
 
Greenhorn
Posts: 14
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Telling someone not to use a singleton for this use case is just pure and utter purist nonsense. Keep it Simple and just use a singleton for this scenario. It would be unwieldy and poor design to make everyone of your classes have to accept a Config parameter in its constructor (or even worse each method call).

Repeatedly saying "global state is evil" without really saying why it would be harmful in this use case is ridiculous. The only concrete reasoning that was provided was testing; however, I test with configuration stored in a singleton all the time. I fail to see why testing is an issue.

Even Grails offers an application properties via global state, sometimes it pays to keep it simple.
 
Stephan van Hulst
Saloon Keeper
Posts: 15484
363
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Do you really have that many methods that require access to an object that bundles all configuration settings? I can understand if you have one or two, but I fail to see how most methods can't just be passed those arguments that are necessary for them to operate properly.

I didn't just mention testing, I also implied that you break data encapsulation. It's much much easier to introduce bugs if everything in your program can access parts they are not supposed to. My advise is that even if you disagree with me about not storing config data in a singleton, at least make the class immutable, otherwise you're just begging for problems.
 
Bartender
Posts: 10780
71
Hibernate Eclipse IDE Ubuntu
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Michael Parmeley wrote:Telling someone not to use a singleton for this use case is just pure and utter purist nonsense. Keep it Simple and just use a singleton for this scenario.


No, DON'T. That's simply substituting simplicity for ignorance.

Repeatedly saying "global state is evil" without really saying why it would be harmful in this use case is ridiculous.


Actually, Stephan has suggested several very good articles on the subject. If you don't want to read 'em, and just go with a 'System' or 'Application' class/object because it's "simpler", that's your look-out.

"Everything should be as simple as possible, but no simpler" - Albert Einstein (paraphrased).

Winston
 
Marshal
Posts: 28177
95
Eclipse IDE Firefox Browser MySQL Database
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
But remember that

Stanley Walker wrote:I have two property files which will be used frequently from a web application....Is there some way in which i can cache these values in server?



And a web application has a feature called the "application context". So the natural solution here is to load the properties files into an application context variable when the application starts, and access that variable whenever you need to get a property from the files.

So (to answer the original question) no, there's no need to write a special singleton class for this requirement. You already have a singleton in place which acts as a global context.

However all the discussion in this thread about why you shouldn't use a singleton is useful. Inevitably when you implement my solution of loading the properties when the application starts, somebody decides that they have to change something in the properties. And then they find out that the web application doesn't pay any attention to those changes until it gets restarted. And often restarting a web application is problematic for various reasons.

So it's certainly worthwhile considering the "No Singletons" option and just reading the properties file each time you want to get one of the properties.
 
Bartender
Posts: 4179
22
IntelliJ IDE Python Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Stephan van Hulst wrote:Do you really have that many methods that require access to an object that bundles all configuration settings?



I think that sentence there deserves to be highlighted as well. The natural thing to do with a singleton is to fill it with all the configuration settings. The next thing you do is use it as a simple place to put everything you think it would be easier get from a central data location rather than passing around. Then you have a single Object that has a lot of configuration and details being shared between lots of parts of the application that don't need to know it all. One of the benefits of having an Object you pass to the methods that it is easier to make those classes contain just the configuration settings needed by the method, and have different objects with different data required by different parts of the application - better protecting the scope of the data.
 
Michael Parmeley
Greenhorn
Posts: 14
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Paul Clapham wrote:But remember that
However all the discussion in this thread about why you shouldn't use a singleton is useful. Inevitably when you implement my solution of loading the properties when the application starts, somebody decides that they have to change something in the properties. And then they find out that the web application doesn't pay any attention to those changes until it gets restarted. And often restarting a web application is problematic for various reasons.



Its trivial to add an operation to your web app that tells it to re-read your property file thereby removing the need for a restart.
 
Michael Parmeley
Greenhorn
Posts: 14
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Winston Gutkowski wrote:

Michael Parmeley wrote:Telling someone not to use a singleton for this use case is just pure and utter purist nonsense. Keep it Simple and just use a singleton for this scenario.


No, DON'T. That's simply substituting simplicity for ignorance.



There is no ignorance involved, I am aware of the "global state is evil" mantra; however, for this specific use case I simply disagree. I simply see nothing wrong with keeping application wide configuration settings in a singleton. If someone could show me an actual reason not to do so that is applicable to the real world I would reexamine my position.


Actually, Stephan has suggested several very good articles on the subject. If you don't want to read 'em, and just go with a 'System' or 'Application' class/object because it's "simpler", that's your look-out.



I have read many such articles on the topic and I haven't read anything to convince me that using a singleton for application wide configuration settings is actually harmful.
 
Stephan van Hulst
Saloon Keeper
Posts: 15484
363
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Programmer A writes a program that accesses globally available configs. Programmer B debugs a method from the program several months later by testing it with dummy config files. The entire program run suffers side effects during testing because the dummy config files are referenced from many other methods.

In big testing frameworks, dependency injection is incredibly important because you can substitute mock objects. This makes testing and debugging *much* easier, and *much* faster. This is significant because maintenance, testing and debugging is the biggest part of the software life cycle. Writing maintainable code in this fashion will save a company many resources.
 
Ranch Hand
Posts: 572
2
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Programmer B debugs a method from the program several months later by testing it with dummy config files. The entire program run suffers side effects during testing because the dummy config files are referenced from many other methods.


This scenario suggests that the two properties, originally mentioned ,are being used for different purposes in different parts of the program.

Configuration properties should mean the same thing to all parts of the program. If changing a configuration property breaks one part of the program but not another,you would want that to show up during testing.
 
Stephan van Hulst
Saloon Keeper
Posts: 15484
363
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
No, it suggests that the same properties singleton is being used in different parts of the program, for different purposes. This is my point.
 
paul nisset
Ranch Hand
Posts: 572
2
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Stephan van Hulst wrote:No, it suggests that the same properties singleton is being used in different parts of the program, for different purposes. This is my point.



Both programmer A and programmer B would want to know that and fix their methods accordingly.
There should not be a problem using a singleton to retrieve static properties like configuration values system wide , if they have have the same meaning system wide.

I guess what I don't understand is how is using singleton that reads in properties from file at startup,different than using a properties file?
 
Paul Clapham
Marshal
Posts: 28177
95
Eclipse IDE Firefox Browser MySQL Database
  • Likes 2
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Let me just point out here that the subject of discussion here is the application context for a web application. This is not a singleton object; an application server will have one of these objects for each web application which is running in the server.

So that means that "Singleton Is Harmful" is not strictly relevant in this discussion. The possible problems which people are raising under this heading are really problems about whether the contents of this properties file can really be considered to be attributes of the web application. Bear in mind that it doesn't matter that the data comes from a properties file; one could have the same discussion about application-level properties which are configured into the application's web.xml file.
 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
reply
    Bookmark Topic Watch Topic
  • New Topic