Caching Technique in Hibernate

[ashwin bala]

Hi all,
I am trying to understand how exactly query caching works.I got different answers from different blogs.
What i understood about query caching is ,in plain words ,the values from the database will be fetched will be stored in cache memory(Its primary key or any id reference
for each row in result set).so when i call the same query next time,my data will be fetched from cached data
and not from database.
For ex:

Session session = getSessionFactory().openSession();
 Transaction tx = session.beginTransaction();
 Query query = session.createQuery("from Person p where p.id=1");
 Iterator it = query.list().iterator();
 while (it.hasNext ()){
   Person p = (Person) it.next();
   System.out.println(p.getFirstName());
 }
 query = session.createQuery("from Person p where p.id=1");
 it = query.list().iterator();
 while (it.hasNext ()){
   Person p = (Person) it.next();
   System.out.println(p.getFirstName());
 }       
 tx.commit();
 session.close();

in the above code the there will be two database hits.to avoid this we use the get Method which checks in session
after that in cache whether data is available. if not it goes to database.
If the above assumptions are correct, where the second level caching comes into picture? please correct me if am wrong. Thanks in advance

[Bill Gorder]

the values from the database will be fetched will be stored in cache memory(Its primary key or any id reference for each row in result set).so when i call the same query next time,my data will be fetched from cached data

Not exactly true.

Lets start off by saying that Query Caching in many cases buys you absolutely nothing. So be careful not to fall into the premature optimization trap. If performance is an issue often making improvements in other areas will have a greater effect.

With that said.

In your example you are not setting the query as cacheable so nothing out of the ordinary is going to happen.

query.setCacheable(true);
query.setCacheRegion("someRegion"); //Region defaults to "org.hibernate.cache.QueryCache"

When the query is executed the first time the results are cached in a cache region.

The whole result set is not typically stored only the SQL statements and bound parameters, and identifiers for the entity instances. If your query returns only scalar values this will be cached as well. This is where the second level cache and persistence context come in. It is their responsibility to store the actual state of the entities. You should never enable query cache without a second level cache. The org.hibernate.cache.UpdateTimestampsCache is automatically present if query cache is enabled and is used by hibernate internally to determine if the queries that are cached are stale. The query cache will use the cached identifiers to look up entity state from the second level cache and/or persistence context.

[Divya Janyavula]

After enabling query caching you can print the sql statements and observe how many queries go to DB when caching is enabled.

[ashwin bala]

To Mr.Bill Gorder: As per my understanding,this query caching is a concept,where second level caching is a part of it.Second level caching is kind of a storage where query cached data are stored (not complete result set).
When the query is fired next time,data will be retrieved from second level cached data.

"It is their responsibility to store the actual state of the entities ". does it mean the latest value from the DB is cached?

And ,If you enable query caching, the query with its parameters,sometimes scalar values like max,min, row count will also be stored in the second level caching area.

Is my understanding correct? And i am sorry if am wrong

To Divya: Yes Divya, i have started but just want to know what is happening in the back ground..

[ashwin bala]

I am finding it difficult to understand with out executing any examples..i will work on this and ask more meaning doubts

[Bill Gorder]

query caching is a concept,where second level caching is a part of it

If you use query caching you should also use second level caching. Failure to do so will actually result in more queries being executed than not using query caching at all. You can use second level caching without query caching enabled however.

Second level caching is kind of a storage where query cached data are stored (not complete result set).

No. Second level cache is independent of query cache and is typically controlled by the developer (this can be tuned with hibernates cache concurrency strategy). The typical strategy is that entities are not cached in the second level cache unless explicitly marked as cacheable. This is important because you will want to make sure any entities that are returned as a result on cached query are marked cacheable, otherwise when you execute a cached query and it goes looking for entity state in the second level cache it wont find anything. If entity is marked as cacheable then all of its state is cached not just part of it.

The query cache (totally separate cache now) will store the identifiers, bound parameters, SQL statements, and scalar results (no entities just identifiers) the rest of the entity state is thrown away (this is why having a second level cache is important). The next time the query is executed if the query is found in the query cache it will look it up (using the cached identifiers) in the second level cache and Persistence Context.

"It is their responsibility to store the actual state of the entities ". does it mean the latest value from the DB is cached?

By 'their' I actually meant it is the responsibility of the second level cache to store the actual state of the entities. And it is the developers responsibility to make sure that the entity is marked as cacheable so that it cached

Does it mean the latest value from the DB is cached?

The latest value that was retrieved is cached. That does not guarantee that the data is not stale for example when something goes around the persistence context (like another application updating the database for example). Hibernate puts a lot of tools out there to avoid stale data. Some of this is done automatically and some of it is your job to configure, they can't possible be aware of every scenario that is applicable in each circumstance.

And ,If you enable query caching, the query with its parameters,sometimes scalar values like max,min, row count will also be stored in the second level caching area.

Nope it will be stored in the query cache which is totally separate from the second level cache.

[Bill Gorder]

ashwin bala wrote:I am finding it difficult to understand with out executing any examples..i will work on this and ask more meaning doubts

Ok Good Luck