Hibernate Caching Technique

Question

I have a application which has 200 tables - classified into 4 groups

1. Non Transactional (50 tables) - Tables like department, designation etc which are updated once a while sometime by admin (100000 reads : 1write ratio & 1write/month)

2. Less Transactional (50 tables) - tables like settings, product, tax rates which are read more and inserted very less often but write occurs everyday (1000 reads : 1 write ratio & 1 write/day)

3. Transactional (50 tables) -tables like orders, receipts etc which are written and read almost equally (10 reads : 1 write & 1 write/hr)

4. Heavy Transactional (50 tables) - tables like tasks, history etc which are written more and read less but used by services & reports (1 read : 1 writes & 1 write/minute)

I am using hibernate, struts2 & spring and looking for caching strategy to get best performance & efficiency.

If you observe i have more data in tables which are written & read most, so caching them in more critical.

Can I cache group 4 tables? If yes how ?

Can I cache group 3 tables? If yes how ?

Can I cache group 2 tables? If yes how ?

Can I cache group 1 tables? If yes how ?

Can I use in memory db for some tables?

Will view help me in some cases? Which cases?

Well what I want finally is a fast read access from in memory database, some thing that will update my in-memory database as database changes. Like say I have products list, orders list in memory but when any new product or order gets added this list must reload themselves. Typically all reads from some in-memory database while all writes to direct db with trigger to update list or list-item.

Answer 1

Lets start with the thumb rule of caching,

Cache the non-transactional data which are read frequently and change rarely.

Hibernate allows you to get there pretty safely. From this point even though still you can use caching it is not really recommended as you might run in to multiple problems with it. So it better to proceed with caution on this. Have a look at the below list of articles, it will give you more insight.

1. Hibernate: Truly Understanding the Second-Level and Query Caches
2. Understanding Caching in Hibernate – The Second Level Cache
3. Improving Hibernate's Performance

So when we apply this rule to your scenario, Only the first set should get cached. Do that first, measure your application for performance improvement. If things are fine you can consider caching the second group also. It is not recommended to cache the transactional tables so the set 3 and 4 are ruled out.

Answer 2

Though ManuPk has answered the question in a very detailed manner,i just want to add a few things, Hibernate provides a local InProc cache that cannot be used in a multi-server environment. so during the peak load times, if the response time is not good and you feel that performance is an issue, you better go for a 2 Level cache. because it allows applications using NHibernate to now scale to multi-server environments and also remove any database bottlenecks. Please read the following article for further reference, though its about NHibernate(.NET)but it'll explain the concept of L1 and L2 cache.

Secondary Level cache, Taking performance ot the next level

you can use NCache as a second level cache as it is now fully compatible with Java and .NET apps. Cheers