[Springframework-developer] Why store configuration in a database?

[Rob B. <rob...@ve...>]

Why would I want to store my configuration in a database?

Simple - security, history, audit trail, centralized management.

Security: With all the configuration data stored in a database it can have
advanced security wrapped around it.  This would allow for tight control
over which parameters can be changed and by who.  Thus providing a much
finer grain of control than file based configurations can.  Operational
staff can be allowed to change some parameters, while other parameters
modifications are limited to developers only.

History: All configuration changes can be logged in the database.  This
could be used to allow rollbacks to configuration modifications if something
got changed that shouldn't have.

Audit trail:  Who changed what when.  This can be critically important if
all of a sudden your application has problems.  See who changed it, what
they changed - you could even require comments so that a reason for the
change can be noted.

Centralized management:  Often an application will have many instances, on
many nodes.  There may also be different environments for each stage of an
application (Development, QA, Production).  If all environments are managed
from a central repository configuration migration can be simplified.  Once
your app is moved out of QA, apply the appropriate configuration updates to
Production...  This is made very easy because all the configuration data is
already in the database.  Just migrate the appropriate portions.

Wrap the database with some JDBC or Hibernate DAO's, and put some JMX mbeans
on top of that.  You now have a fully JMX enabled configuration system.

Someone had previously mentioned that they didn't like having configuration
data stored in a database because if you had two machines using the same
database for configuration, you would have to update both, or neither.  This
is not necessarily true.

Spring supports the concept of "contexts".  Why not extend this concept to
encompase a larger realm.  In addition to the app global, and servlet
specific contexts that Spring already supports we can add:

/geographic location
/cluster
/node
/application
/instance
/spring's existing app global
/spring's existing servlet specific

All the "contexts" above Spring's existing contexts are arbitrary.  Define
as many as you want / need.  Now you can change the application
configuration on one instance of an application, and then migrate those
changes to the others as you need.  You can also continue to move the
configuration changes up the context hierarchy or copy configuration changes
from one context to another.  No changes to Spring should be necessary for
the addition of these higher level contexts.

Whatever mechanism you decide to use for moving your configuration data out
of the database and into your application would "handle" the higher level
"contexts".  For example, if you were using the JdbcBeanFactory you would
write your SQL query so that it would obtain only the appropriate
configuration data for it's "context".  So, if you had a context of
/cluster1/node1/app3/instance2 you would have your JdbcBeanFactory specify
that as part of it's SQL so only that data was retrieved (or other
parameters which were higher up in the context, but not over-ridden in a
lower context).

Another option would be to use JMS to send updated config parameters to your
app.  A MDB or the like would listen for any message, and upon receiving one
update the appropriate files for your app.  It could then signal your app to
reload it's configuration data using the updated files.  This has the added
benefit of "caching" your configuration data.  I.E. if your configuration DB
is down, your app can still start up with the copy of the configuration that
is on it's HDD.

If you didn't want to use a database, you could have JMX mbeans directly
update the Spring config files, and then signal Spring to reload.  This way
your JMX config changes are saved so they will still be in effect the next
time your app is started.

Now all that is needed to make Spring fully dynamic is a way to "reload" a
configuration while your app is running.  I've got a few thoughts on this
too, but this e-mail is already long enough.

Thoughts / comments?

Later
Rob