aspose file tools*
The moose likes Java in General and the fly likes Caching property values in server memory Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » Java in General
Bookmark "Caching property values in server memory" Watch "Caching property values in server memory" New topic
Author

Caching property values in server memory

Stanley Walker
Ranch Hand

Joined: Sep 23, 2009
Posts: 87
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
Stephan van Hulst
Bartender

Joined: Sep 20, 2010
Posts: 3649
    
  17

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

Joined: Sep 23, 2009
Posts: 87
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?
Prabaharan Gopalan
Ranch Hand

Joined: Oct 16, 2009
Posts: 66

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.


Googling doesn't make you a genius. But not Googling makes you dumber.
Stephan van Hulst
Bartender

Joined: Sep 20, 2010
Posts: 3649
    
  17

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

Joined: Oct 16, 2009
Posts: 66

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
Bartender

Joined: Sep 20, 2010
Posts: 3649
    
  17

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

Joined: Oct 16, 2009
Posts: 66

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
Bartender

Joined: Sep 20, 2010
Posts: 3649
    
  17

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
Bartender

Joined: Sep 20, 2010
Posts: 3649
    
  17

This is also an interesting read: http://c2.com/cgi/wiki?GlobalVariablesAreBad
Michael Parmeley
Greenhorn

Joined: Aug 20, 2004
Posts: 14
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
Bartender

Joined: Sep 20, 2010
Posts: 3649
    
  17

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.
Winston Gutkowski
Bartender

Joined: Mar 17, 2011
Posts: 8427
    
  23

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


Isn't it funny how there's always time and money enough to do it WRONG?
Articles by Winston can be found here
Paul Clapham
Bartender

Joined: Oct 14, 2005
Posts: 18991
    
    8

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.
Steve Luke
Bartender

Joined: Jan 28, 2003
Posts: 4181
    
  21

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.

Steve
Michael Parmeley
Greenhorn

Joined: Aug 20, 2004
Posts: 14
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

Joined: Aug 20, 2004
Posts: 14
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
Bartender

Joined: Sep 20, 2010
Posts: 3649
    
  17

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.
paul nisset
Ranch Hand

Joined: May 13, 2009
Posts: 177
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
Bartender

Joined: Sep 20, 2010
Posts: 3649
    
  17

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

Joined: May 13, 2009
Posts: 177
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
Bartender

Joined: Oct 14, 2005
Posts: 18991
    
    8

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.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Caching property values in server memory