Home arrow static arrow Java Programming [Archive] - Caching vs reading from db
Warning: Creating default object from empty value in /www/htdocs/w008deb8/wiki/components/com_staticxt/staticxt.php on line 51
Java Programming [Archive] - Caching vs reading from db
This topic has 2 replies on 1 page.

Registered: 4/3/01
Caching vs reading from db  
Jul 1, 2004 1:39 PM


I need to write a function that validates the zip code. All the zips are present in the db tables.
Now my question is , is it advisable to cache (static data) all the zip codes ( in US) around 11000 zipcods by reading once from the database , and validate the zipcode against the cache, or is it advisable to perform a query on the database using the zipcode that is entered.
I am implementing this in the DAO layer ( J2EE architecture), weblogic server., Oracle db.
I know validating against the cache would perform better, but will it blow up the memory ?

Could you please suggest.

Thanks in advance.

Registered: 1/23/02
Re: Caching vs reading from db  
Jul 1, 2004 1:46 PM (reply 1 of 2)

You can reprezent a ZIP as an int. 11000 ints is about 43Kb. That's not going to "blow up the memory".

A database round trip is about the most expensive operation you can do in a J2EE application. In this case you can avoid it. However I'd be surprised if ZIPs are the only thing you need to validate in the application. Quite probably you already have some coding go to the database to do some validations. In which case you could piggy-back on that.

Registered: 3/30/99
Re: Caching vs reading from db  
Jul 1, 2004 1:58 PM (reply 2 of 2)

Another point to consider is where will the ZIP come from? Is it always entered by a human? How many humans per unit time to you expect to be entering the ZIP? (e.g. 1000 / sec or 50 / hr or whatever) What other processing are you doing in response to that user action?

A single DB rountrip to validate the ZIP I just entered is probably very fast compared to the time it took me to enter it, and if you're doing other processing in response to my clicking of Submit or whatever, then that DB access becomes even less significant.

On the other hand, if there are 100 or 1000 or 10000 of "me" entering a ZIP and hitting Submit very close together in time, then I might end up waiting for hundreds or thousands of lookups, not just the one for my ZIP.
This topic has 2 replies on 1 page.