How much of a performance hit are we talking when doing a JDBC lookup versus a properties file lookup?
We have a simple property that needs to be looked up, either from the database or a properties file. A lookup on the file system is probably faster than a JDBC lookup, but the question is is it worth it?
We have 8 app servers - so that means one change to a property means updating 8 files (one on each server). Whereas if we put the property in the databae we only have to change it in one spot.
In my opinion, the slight performance hit associated with the JDBC option is worth it to avoid maintaining 8 files. What do you all think?
Scott, I recommend the property file approach. What if you have a property that is specific to an app server, but not a database/environment? This could happen if you have clones and one node needs a different value than the other. Conceptually, the properties go with the app server, not the database.
If you have some spare dev cycles (which it sounds like you do if you are considering a JDBC solution), you could write something to automate the file generation. We maintain ONE set of property files - the ones used when testing locally. We also maintain a file of "Environment Differences." Our automated build does a search and replace to create the files for each environment. Even if you don't have an automated build, you could still write a quick utility to do a search and replace.
Originally posted by Jeanne Boyarsky: We maintain ONE set of property files - the ones used when testing locally. We also maintain a file of "Environment Differences."
Good point to bring up. I often use the environment name as part of the property name in the property file, like so:
It's pretty simple to write a custom property class that appends the environment name with the property name and retrieves the environment-customized property. If it doesn't find the environment-specific property, it returns the default value. Simpler build process at the expense of a more complex property file.
Joe, That sounds logically equivalent to what we are doing. One thing that doing this at build time buys is the validation that we didn't forget to set a production property. I guess you could write a validator for the property file to accomplish this.
I was very happy with a system that used a database instead of properties. It fit the granularity for us: one database per environment (DEV, QA, PROD). The few things that had to be clone-specific (like only one clone in a cluster runs service x) were very stable and were in WebSphere properties. An older XML based design was left in place with higher priority, so developers could use a shared database but override individual properties in their own environments.
For performance, we cached what we read and had the ability to purge part or all of the cache in a running system, so we could update the database and hit a button to make all servers read from the database again. I thought FIT would be a neat way to document what you think is in the database and check to see if it's right.
I'm in a group now that uses bazillions of real properties files with different versions for different environments. It works ok but scares me ... there are many ways to screw it up.
A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi
Yup, yup, yup. Tiny ad:
a bit of art, as a gift, that will fit in a stocking