Dynamic (Runtime) Code Configuration Changes?

Discussions

General J2EE: Dynamic (Runtime) Code Configuration Changes?

  1. Hello,

    I'm interested in the options for reconfiguring code at runtime. Has anyone done this successfully? If so, please explain how.

    I've come across a few articles:

    http://www.javaworld.com/javaworld/jw-04-1999/jw-04-cooltools.html
    - this one describes a setup that loads configuration items directly from database tables. it also supports an expiration interval to allow for different caching settings. however, there is no way to force an update unless you set it to check the database at every time.

    http://www.javaworld.com/javaworld/javatips/jw-javatip125.html
    - a similar method to that above where you set a file listener by timer. seems inefficient as you're reading from disk and also does not support clustering very well

    http://www.informit.com/articles/article.asp?p=28794&redir=1
    http://www.informit.com/articles/article.asp?p=29011
    - these articles seem the most interesting as the author clearly understands all the issues of configuration. it makes the Preferences API seem pretty useful, and you could probably write a custom Preferences implementation that would perform runtime access via database lookup, etc. In the second article, the author puts forward a more robust configuration interface. Has anyone seen progress on such an interface?

    We'll be running J2EE applications that we want to be able to change parameters on at runtime (for a zero-downtime scenario). The solution should support clustering as well as full production-level operation.

    This seems to be an important topic, but it's hard to find much info.

    Thanks!
  2. I don't have much experience with hot upgrades. It goes back a few years back.

    The main problem we were facing was the caching of outdated information (in components and as well as configuration service). Simply put, we had to install versions on our configuration. The latest version id (flyweight) would be put into the user's session when he logged in. This way he would have a consistent behaviour from the system. When no users had a specific old version of configuration, we would cut the references to the appropriate classes, allowing it to be gc'ed. The system would of course not give a reference to a failed configuration reload.

    I believe we had config files on nfs (or some other shared fs) that were reread when the system received an http request to reload.

    I hope this is helpful even though the technique might be outdated,
    sv