We're in the early stages of the project and would like to use Hibernate. Have a design question that I could use some guidance on, as I'm very new to Hibernate.

Our object model will have a definition of a LOOKUP_DOM and LOOKUP_DETAIL_DOM with one-to-many relationship (many details exist for each lookup). So the application will hold references to the LOOKUP_DOM object which will contain a Set of LOOKUP_DETAIL_DOM objects.

The DB table containing DETAILS will be updated throughout the day via an MQ interface periodically throughout the day.

Meanwhile, the LOOKUP_DOM will be used repeatedly in the application, so we'd like to take advantage of some caching of values (as much as possible) to avoid making a trip to the DB every time the LOOKUP_DOM is referenced, but I have to make sure the data referenced in the structure is not stale...

Assuming I map the relationship properly, can Hibernate help me with the Caching of the values, AND will it be able to 'recognize' the changes to the underlined DB values and refresh the data in the mapped objects? That's what I'm having trouble understanding... how much work can Hibernate do for me in this case, and how much work I have to do to make sure my DB and DOM objects are in synch such that the applicaiton isn't using stale data.

Please help clarify.

Thanks,
James

Hibernate can help quite a bit under those circumstances. Read up on chapter 19 in the reference manual. It sounds like you would benefit from implementing a second level cache to hold instances of both LOOKUP_DOM and LOOKUP_DETAIL_DOM objects, coupled with implementing the query caching mechanism. The query cache, in particular, is what will benefit you the most. You will be able to code your application in a normal Hibernate fashion, using queries (HQL or Criteria), and the query cache should detect stale data by checking the underlying table's last modification date (checking the UpdateTimestampsCache). In other words, the query cache will transparently return cached instances for the same query as long as the underlying table has not changed since the last execution of the query. If the table's modification timestamp has changed since the last run, it will invalidate the cache entries and rerun the query by hitting the database (whereupon it will cache the new entries).

I've read up on Second Level Cache (Section 19.2 in Hibernate 3.2.2 doc) - it states: "Be careful. Caces are never aware of changes made to the persistent store by another application...". Hmmm...

It looks like cache eviction/invalidation must be handled by the custom applicaiton code?!

Again, I'm looking to combine the efficiency of Query Cache (which I believe uses Second Level Cache in tandem) to achieve maximum performance gains of my queries and a the same time allowing feeder application to periodically update the underlying data store. How can I gain the maximum perfomance of the cache without risking fetching stale data?!

Could someone comment please?!

THanks,
James

The query cache will automatically (via the UpdateTimestampsCache) invalidate stale data. It does this by checking the table's last update timestamp against the cached version.

The second level cache must be used with a bit of caution since an external application is updating data. Is this data injected on a periodic or ad hoc basis? If the former, a Quartz job (or the equivalent scheduling job) can invalidate the cache at specified periods. I have not looked at the ehcache (or other cache provider) docs in a while, but scheduled invalidation may also be configurable from there. If the latter, perhaps a hook into the cache (e.g. via JMS or the equivalent) can invalidate. Additionally, the underlying caching mechanism (be it ehcache or other) may also have additional hooks to invalidate cache entries. I'd check the docs for the Hibernate supported cache providers and see how they all function.