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

[Rod J. <rod...@in...>]

Rob,

As Dmitriy pointed out, you might want to check out the JDBC bean factory.
It's pretty simplistic, and you're the first user who has asked about
storing config in the database, so you may want to enhance it and provide a
patch.

My experience has been that putting a small minority of config in the
database can make sense. But I've seldom seen good results from putting
_all_ config in the database; it gets so complex. So perhaps an ability to
_override_ XML definitions in the DB would make sense, as we have overriding
from properties.

I like your suggestions regarding a wider range of contexts. I think a
"cluster-wide" URL context is an obvious candidate. It shouldn't be too
difficult to open a web app up to this. Juergen, what do you think?

Regards,
Rod

----- Original Message ----- 
From: "Rob Butler" <rob...@ve...>
To: <spr...@li...>
Sent: Wednesday, November 19, 2003 1:54 AM
Subject: [Springframework-developer] Why store configuration in a database?


> 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
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: SF.net Giveback Program.
> Does SourceForge.net help you be more productive?  Does it
> help you create better code?  SHARE THE LOVE, and help us help
> YOU!  Click Here: http://sourceforge.net/donate/
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>