Update Timestamps Cache in Action

We saw the query cache in our previous post. We know that UpdateTimestampsCache is only used for query caching. I decided to try and bring it into play in this post.

The Query Cache

In the previous posts we saw the Hibernate cache system and the Cache modes. We saw the query cache is disabled by default.

Hibernate's custom annotations

In the previous few posts we saw how JPA provides us with an annotation driven approach to configure our entities. As with all standard APIs, when vendors implemented JPA, they found that the annotations did not cover every nifty trick provided by the implementations.

CacheModes in Hibernate - continued

In the previous post we saw the GET and IGNORE values for CacheMode. The other values are PUT and REFRESH. Consider the below code:

CacheModes in Hibernate

Hibernate offers us a CacheMode option. This is something that allows us to control the behavior of the second level cache. Consider the below code:

Testing out the cache

In earlier posts we saw the settings needed for configuring Hibernate's second level cache and the various caches providers supported by Hibernate.
To test out the configurations for Eh Cache, I simply executed a main method to start and create a session factory.

How to cache ?

In the previous post we saw how to setup the cache provider for Hibernate. But that is not the end of the story. We need to decide what kind of concurrency we need. Does our data ever change? Can we live with stale data? All these factors are decided by the concurrency strategy we use. Hibernate provides us with four built in concurrency strategies (as of version 3.0):

Hibernate Cache Framework

The Hibernate framework comes with a complete caching system. This cache system is used to reduce the amount of SQL queries fired in the system.
The Hibernate cache is built at two levels - a first level or session cache which we saw earlier and the second level cache. While the first level cache is non optional, the second level cache needs to be configured and switched on for use.

Can we mark entity classes as final ?

We have already seen that Hibernate extensively uses proxies. It uses proxies when we call load, it uses proxies for lazily loading associations and collections.But what if our entity class was final ?

Result Transformers

In the previous post we saw the need for ResultTransformer, how using the value of Criteria.DISTINCT_ROOT_ENTITY filters duplicate records.

Why the need for ResultTransformers ?

Consider the below criteria example which simply loads the Entity records from the database with ids less than 6.

session.createSQLQuery()

Hibernate provides us with the option to fire explicit SQL queries. But with the presence of HQL and Criteria why would one want to do that ?

Getting the total records while using pagination

We often have grids in our application where we need to show the results as pages. There is also often a row of text making the claim " Record  1 to 30 of 100". While the bounds of the result can be obtained easily as we know the limits to apply, it is getting the total record count that is interesting.

Select in Criteria using SQL

In an earlier post we saw how Criteria provided us with the ability to add restrictions in the where clause using pure SQL. The next question would then be if Criteria allows SQL in select clause ?

Criteria and Aggregation

We saw aggregate functions with HQL. Criteria too has methods that provide for using aggregate functions. Consider the below code that simply fetches the count of all rows.

criteria.setProjection()

In previous posts we have seen how to use the Criteria interface. We have also been using the setProjection method when needed to select properties or objects from the executed query.

Working with the Iterator

Before I start let me state that I am still to come across a valid scenario in actual application code where I could find this functionality useful.

Criteria and Inner joins

Few posts ago we saw HQL's extensive support for joins. I decided to check out Criteria's claims to the same. I decided to start out with Inner joins.

SQL inside Criteria

We earlier how a custom criterion could be created to handle special scenarios. However this may seem overkill if the condition can be easily expressed using native SQL. For Criteria allows us to add custom SQL expressions which get added in the where clause.

Restrictions AND OR

I need to execute a query to fetch all entities with id is greater than 5 and the names start with "ent". That means there are two distinct conditions. Doing that using HQL would be pretty straightforward: