Database-driven Web Application Configuration

Given that most two-tier applications have a database, why not store all the configuration data in a table in this database?

Features

The database used by the application stores all configuration data for the application itself
A table of name-value pairs stores the information
SELECT statements can be used to retrieve the information.

Does not need another database in the system.
Database security can be used to restrict access to read-only to most callers.
Configuration is shared across all machines in a cluster.
Configuration can be updated transactionally.
The application's preferred O/R mapping technologies (JPA, Hibernate) can be used to provide access to the data.
If the values are not cached, dynamic changes can be picked up immediately.

A means of defining the database binding is still required: the JDBC URL and login.
Configuration is not kept under SCM; there is unlikely to be a history of previous state.
Configuring the database is now part of the deployment process.
Reading of individual settings by multiple SELECT statements can be slow, especially if done over a network. The best approach is usually to bulk-read all of the values at startup and then extract the values needed.
There's usually no history in the database state; though you can backup and restore the tables.
Relational databases are inherently not hierarchical, but hierarchies (or trees and graphs) are actually quite useful when describing system configurations.

SmartFrog's database components can be used to create a database, and to deploy the database itself. It can ensure that the database is functional before trying to bring up the web application.

The [sf-woodfrog] components can be used to persist SmartFrog's own state to a database. A complete tree of SmartFrog components can be saved to a database, then restored.