How to deal with configuration data in a (web) application?

[Ruben Matthews]

Hi,

How do you deal with info that should be available to the application at all times and fast? My web application contains sections. I allow the administrator to specify a list of parameters for each section, like this

GoogleAds.displayStyle=sleek
ShowNewsTicker=1
NumberOfArticlesinTicker=10


I am going to store these parameters in the database, but I don't want the application to access the database everytime they are needed, because they are needed for almost every page request and they don't change very often. How can I make sure these paramaters are retained in memory (for instance in a Map) and used from there, untill I specifically tell the memory to forget them.

I am hoping for a solution that will allow me to reload the variables into memory without restarting the application server (Tomcat). Would that be possible?

[Bauke Scholtz]

Either store them in a static variable (general) or store them in the application scope (webapplicaiton).

[Ruben Matthews]

Thanks. When using application scope, how would I make sure the parameters are there from the application start? Could I use a static initialization block for that?

[Carey Evans]

You can write a ServletContextListener, or just use your servlet’s init() method.

[Bear Bibeault]

I store such values in a properties file that is read during startup by a context listener which stores the values as a Map in application context.

[Edwin Stephens]

You might want to investigate using the Apache Commons Configuration library at http://commons.apache.org/configuration/index.html. It allows you to deal with configuration data using a variety of sources such as properties files or databases.

In a web app, loading the configuration data at startup can be done both with a ServletContextListener and the init() method of a servlet. Although I've heard the ServletContextListener way is more proper, I tend to use a servlet's init() method, since I can control when the servlet is loaded (via load-on-startup) in relation to other servlets, so that config data can be initialized before other servlets need that data.

Another thing to be wary about is if you're working in a multi-app server environment. If you need to refresh your data, make sure you have a mechanism that can do so across app servers, since you would need to perform the refresh across JVMs.

Edwin

[Ruben Matthews]

Hi,

Thanks for your replies. I have created a solution with statics. I use a static init block to get the properties which are then stored in a static variable as a Map. That works fine.

The init block that gets the properties however depends on a Hibernate session. I now use two static init blocks in the same class. The first on creates the Hibernate session, the second one uses that to retrieve the properties. This works ok, but these activities actually belong in separate classes. Is there a way to know or control in what order static init block are loaded if they are in different classes?

@Edwin: that is a good point you're making about the app servers. I am not sure how I would deal with this. Is clearing each app server by requesting a JSP at each server a good idea? Or would that be that ugly?

[Carey Evans]

Ruben Matthews wrote:Is there a way to know or control in what order static init block are loaded if they are in different classes?

Static blocks are run in the same order as the classes are loaded. I wouldn’t rely on this for ordering, myself, and it makes testing quite difficult. If you’re really unlucky, they’ll get loaded from a thread that can’t access JNDI in some application servers. I would prefer to write an init/reload method on the object to call from the servlet init(), and from whatever reloads the configuration.

[Bear Bibeault]

This is one of the reasons I would not use this approach. That, and that it requires a re-compilation to change the data.

I think that you are setting yourself up for a world of grief by using the static member approach.

[Ulf Dittmer]

Edwin Stephens wrote:Although I've heard the ServletContextListener way is more proper, I tend to use a servlet's init() method, since I can control when the servlet is loaded (via load-on-startup) in relation to other servlets, so that config data can be initialized before other servlets need that data.

Context listeners are run before any servlet is initialized, so that shouldn't be an issue. While the load-on-startup technique works fine, for new development I'd recommend to use context listeners instead. Having a servlet just for initializing stuff -which is not actually being called- is kind of a hack.

Ruben Matthews wrote:@Edwin: that is a good point you're making about the app servers. I am not sure how I would deal with this. Is clearing each app server by requesting a JSP at each server a good idea? Or would that be that ugly?

I'd say that's a hack one wouldn't want to keep in place long term. But generally, if you have an application that's used on multiple servers, then it's time to centralize those config settings (in a DB), and provide a GUI for them so that they can be edited at runtime (where applicable).
You could put a timestamp into the config table, and have the app servers periodically check that. Then they'd reload the settings if the timestamp is newer than the config data they're currently using.