I introduced a configuration database table for just the reasons you describe, plus one more. Our deployment people want to deploy an EAR file and nothing else. So the config files must be in the EAR and since we cannot modify the EAR that makes them the same in all environments:
test, qa, s&p, training, prod, etc. We have quite a few things that must vary in each environment, so those go in the database. It's set up so a configuration file overrides the database. That lets a developer customize his own environment through files without changing a shared database. The configuration module has a lazy cache to improve performance and an administrative dashboard to clear cache and bring in changes.
Any of that sound good?