J2EE Cluster: Is there a generic way to handle central configuration?

We develop an application which is normally deployed on a single webserver. Now we check how it runs in a clustered environment, as some customers are using clusters.

The problem is the app creates a local configuration (in registry/file) which does not make any sense in a cluster. The config is changed by the application. Is there a generic way (like an interface) to make a central configuration, so the config(-file) itself is not duplicated on each node when the app in deployed in a cluster? Any other recommended options? (doing it manually with config on network-share/in database/some MBean?)

why generic? It mu开发者_C百科st run on different application-servers (like tomcat, jboss, Webspere, weblogic ...) so we cannot use some server-specific feature.

Thanks.

Easiest way for central configuration is to put it on the file system. This way you can mount the file system to your OS and make it available to your app server no matter what the brand or version.

We do this for some of our applications. Shared libraries and/or properties files that we care about (in our case). We set up either JVM parms or JNDI environment variables (trying to move toward those) so we can look up the path to the mounted drive at runtime and load the data from the files.

Works pretty slick for us.

Now if you are writing information, that's a different story. As then you have to worry about how you are running your cluster (is it highly available only? load-balanced?). Is the app running in both clusters as if it was one app? Or is it running independently on each cluster node? If so, then you might have to worry about concurrent writes. Probably better to go with a database or one of the other solutions as mentioned above.

But if all you are doing is reading configuration, then I would opt for the mounted file system as it is simplest.

You may use a library like Commons Configuration and choose an implementation which is cluster-friendly like JDBC or JNDI.

I would consider JDBC and JDNI first, however if you want your servers to be able to run independantly, I would suggest a file distrubtion system like subversion/git/mercurial i.e. if your central configuration servers is down or unavailable, you don't want production to stop.

A version controlled system provides a history of who made what changes when and controlled releases (and roll back of releases)

One way to avoid the issue of the central server adding another point of failure is to use a databasse server which you already depend on (assuming you have one) on the basis that if its not running, you won't be working anyway.