Pit Falls in Java Development

Author: Apurba

In this blog, I take a look at the query cache, well it is more than a cursory glance, would try to dive in some detail. The blog would explain some of the details of it (enough introduction, lets get to the meat).

As most of us already know, hibernate supports plugging in external cache providers for addressing certain aspects of performance. There are some very good articles on hibernate caching, some of which are
Understanding the second level and query cache
Chapter 19: Improving performance

Lets start with what we are trying to achieve by query cache. The intention is to cache the results against the query (the sql along with the parameters and their values). The effectiveness of the cache is determined to a large extent by its invalidation logic. The isolation level semantics that we want the cache to follow also impacts this logic. In this blog I will go over some of the these details and how it impacts some of the performance choices I need to make. Rather than detail the implementation logic, will run over some common scenarios explaining the implementation detail along the way.

Natural Key Lookups
A lot of heavily used data is cached at the second level. However, most of this data is looked up using its natural key, the second level cache however would store it using its primary key as the key, so we could go ahead and use the query cache to save this lookup. In an implementation like this, the query cache invalidation logic plays a huge role.

We have to understand that the query cache is leveraged by many other types of queries too, so the safest invalidation logic is to mantain update timestamps for each table. When any value is looked up from the query cache, we would also check if any of the tables involved in this query have been updated since the results were cached, if they were, the safest thing to do is query the db again. This is from a very simplistic point what hibernate does. It maintains the timestamps in the update timestamp cache. The query results are cached with the query as its key in the query cache.

The way the query cache maintains this values also impact our natural key lookup logic, since hibernate in its query cache disassembles the results and stores only the primary key for queries that return results of only one type, we also need to cache the entities with the natural key at the second level.

In simple words the way query cache would work in this scenario is something like

1. check query cache for the query
2. if results are found, check if they are uptodate (that is no entry in update timestamps table or one which predates the cache)
3. if they are assemble the object (assembling involves creating the object from its primary key or group of columns from their values or other strategies)

The thing to remember is that the invalidation logic is “timestamp per table” based, an update on any field of a particular table would invalidate the cache for all queries using this table. For this reason the query cache approach may not be a great fit for natural key queries. Hibernate does provide criteria queries which are much better suited to Natual Key, in case of Criteria keys, since we mention that the fields used are natural keys, hibernate query cache is smart enough to understand that we can bypass the uptodate check and depend on the assembling logic for handling it properly.

A smarter hql translation to support hints for the standard query cache for natural key logic or an inbuilt memoization approach that translates natural keys to primary keys and then queries would have been really handy for this type of work.

In the next set of blogs will try to get into the cache concurrency strategy and how it impacts us from a performance perspective.