Properties File Versus JDBC Lookup

[Scott Maclary]

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?

[Joe Ess]

 

Originally posted by Scott Maclary:

We have 8 app servers - so that means one change to a property means updating 8 files (one on each server).

You are not using source control and an automated build? That's a Bad Idea.
My preference is to use a database to store data that I will be running queries against. For everything else, flat files.

[Bimal Patel]

How huge such properties file data would be? How about using JDBC lookup and caching data into server session at the start of App. server?

[Jeanne Boyarsky]

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.

[Pat Farrell]

First, I have to second the comments that you need svn/cvs/something that supports proper versioning.


Don't you have to have a property file to contain your JDBC properties? You don't want to hard code them, do you?

Adding one more property to a small file has no performance impact.
If its "big" and there are "lots" of properties, then a database makes sense. Or perhaps serialize all the properties to disk.

[Joe Ess]

 

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:

property1=w
property1.test=x
property1.staging=y
property1.production=z

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.

[Jeanne Boyarsky]

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.

[Stan James]

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.