Question

I’m developing a webapplication using Java EE with JPA. Now I’ve come across a few values that I need saved for one instance. E.g.: name of the webapplication, taxnumber, contact data. Some of these values can be changed by the CMS.

What would be an efficient way to save these data?

• Entity object: I don’t feel right by making an object for this, saving it as an Entity. This way it would create a table with only one entry. I would need to make a DAO to access it too.
• Properties file: I don’t want to lose any changes after running a new version of my WAR. Secondly I think there might be a better solution than editing properties files.
• Applicationscoped bean: I don’t want my data to be lost upon restarting the application for whatever reason.

Is there another more efficient way to handle values like these? Or should I use one of these ways, if so, why?

Thanks for your input!

Answer 1

I’m not sure of enough of the specifics of your application to be able to say for certain which will be best, but my thoughts on when to use what type of setting storage is:

• Database (settings table) – really thrives where you will have values that will be changed independently of what happens with your source, the values are environment specific, or people who you don’t want mucking around on your file system will be changing the values (ex. whether a feature is enabled on the environment, which server to talk to for some type of request)
• Properties file – good for when you have data that will be set on a per machine basis in you cluster (although I would suggest standardizing everything in your cluster), or when your CMS will be the primary (only?) way of setting the properties and you will be replacing the file with each install
• Application bean – The setting is needed at application startup (ex. the number beans to spin up, or the database connection string)
• In code – The value will never be changed… ever (ex. application name)

The most efficient way to store a setting will be in code directly, but it is so inflexible that it isn’t worth it in most cases. Storing the property on the file system as opposed to in the database will be about the same assuming you have caching for your database and are reading it from the database every time you get the property. If you don’t have caching then you will be paying the price of a disk read every time you access the property where as a property file will store the value in memory after it is read.

For ease of changing the value, I believe that storing it in the database is the easiest way to change it (assuming you aren’t changing it across a lot of different environment frequently) because you can change it while the application is live and have it take effect quickly. If you have the property in a file on the file system you either need a way to force your application to re-read the property while it is running, or you will have to bounce your application to change the property. If you have it in code you have to respin your build to effect the property (obviously).