aspose file tools*
The moose likes Performance and the fly likes Properties File Versus JDBC Lookup Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Soft Skills this week in the Jobs Discussion forum!
JavaRanch » Java Forums » Java » Performance
Bookmark "Properties File Versus JDBC Lookup" Watch "Properties File Versus JDBC Lookup" New topic
Author

Properties File Versus JDBC Lookup

Scott Maclary
Ranch Hand

Joined: May 11, 2005
Posts: 34
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
Bartender

Joined: Oct 29, 2001
Posts: 8994
    
    9

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.


[How To Ask Questions On JavaRanch]
Bimal Patel
Ranch Hand

Joined: Aug 29, 2003
Posts: 130
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?


Work Hard, Expect The Worst...<br /> <br />Bimal R. Patel<br />(SCJP 1.2, SCWCD 1.4)
Jeanne Boyarsky
author & internet detective
Marshal

Joined: May 26, 2003
Posts: 31054
    
162

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.


[Blog] [JavaRanch FAQ] [How To Ask Questions The Smart Way] [Book Promos]
Blogging on Certs: SCEA Part 1, Part 2 & 3, Core Spring 3, OCAJP, OCPJP beta, TOGAF part 1 and part 2
Pat Farrell
Rancher

Joined: Aug 11, 2007
Posts: 4659
    
    5

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
Bartender

Joined: Oct 29, 2001
Posts: 8994
    
    9

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.
Jeanne Boyarsky
author & internet detective
Marshal

Joined: May 26, 2003
Posts: 31054
    
162

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
(instanceof Sidekick)
Ranch Hand

Joined: Jan 29, 2003
Posts: 8791
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
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Properties File Versus JDBC Lookup