This week's book giveaway is in the Mac OS forum. We're giving away four copies of a choice of "Take Control of Upgrading to Yosemite" or "Take Control of Automating Your Mac" and have Joe Kissell on-line! See this thread for details.
We are using some lookup tables. We decided to use Hiberante caching for reducing database hit. Whether First-level or second-level caching(EHCache) suits our scenario ? Normally caching suits maximim of how many records(without affecting performance) ?
If you look at the above website and under the Hibernate Caching heading there is a nice explanation of First-level vs. Second-level caching.
First-level attaches the cached data to the session. Second-level attaches the cached data to the session factory.
So, personally I would recommend using Second-level caching (if you're using the session per request hibernate design pattern). However, there is a price to pay with Second-level caching. The data that is cached will never be updated from the database.
Now, there are a few ways around having stale data in your cache.
1.) Restart your application when there is a change. 2.) Don't use hibernate caching and store the data needed in a static class or singlton and have a way to query the database to update that cached data. (I do not know if there is a way to request hibernate to update its Second-level cache at this time. My guess is requesting a new session factory would do the job, but it does take a while to generate a new session factory.) 3.) Don't cache the data. (Are the database hits causing a perceived slow down on your application? Have you run your code through a profiler to see if the database calls are slowing your application down? etc...) It is not always necessary to cache data from lookup tables. I'm sure some people will disagree, but until there is evidence from a profiler for any type of "speed enhancement" I shy away from programming them myself.
Hope this helps. [ August 30, 2007: Message edited by: Nathan Hook ]