January 20, 2021
Hot Topics:

Combining Hibernate Cache and Ehcache for Better Java Scalability

  • By Jacek Furmankiewicz
  • Send Email »
  • More Articles »

Spring, Hibernate and Ehcache in Practice

Attached to this is article is a sample application that shows how this all works in practice. It exposes a simple REST service for a basic Person entity under http://localhost:8080/services/person and requires Maven to run. The sample Log4J configuration is set for TRACE for both Hibernate and Ehcache in order to show the most information about what's going on under the hood.

When you start the application via mvn jetty:run it will show a long list of trace messages, out of which the key ones are:

Cache region factory : net.sf.ehcache.hibernate.EhCacheRegionFactory...Creating EhCacheRegionFactory from a specified resource: /com/developer/ehcache.xml.  ...Building cache for entity data [com.developer.article.model.Person]Couldn't find a specific Ehcache configuration for cache named [com.developer.article.model.Person]; using defaults.started Ehcache region: com.developer.article.model.Person

Now via the standard Linux curl command (or any other REST client on your PC platform) we will send a GET request to our REST Web services to get a JSON representation of a single Person entity that we have in our database:

curl http://localhost:8080/services/person/6{"Person":{"id":6,"firstName":"First 3","lastName":"Last 3"}}

Let's look at the server-side log to see what happened on that first request:

adding entity to second-level cache: [com.developer.article.model.Person#6]done materializing entity [com.developer.article.model.Person#6]

Hibernate retrieved our entity from the database, stored it in the cache automatically and returned it to us. Now let's issue the same curl command again and see what happens:

loading entity: [com.developer.article.model.Person#6]attempting to resolve: [com.developer.article.model.Person#6]assembling entity from second-level cache: [com.developer.article.model.Person#6]

This time Hibernate automatically found our entity in the cache and loaded it directly from memory without hitting the database -- which was the main reason we wanted to use second-level cache in the first place.

Effective Strategy but Nothing Is Free

This of course sounds great and looks easy. However, all of this comes at a price, namely increased complexity (especially during testing). By relying on cached entities, you risk having an out-of-sync cache when an update happens in the database via a different request.

As such, you must analyze every entity that can be cached to determine whether serving a potentially stale copy of it is acceptable. Stale copies may be fine for fairly static entities that rarely change, but they would not be appropriate for something such as a bank user's Account object, which should always reflect the latest state in the database.

However, options are available for handling those situations. For example, you can configure Ehcache to do multicasting over the network in order to update the caches automatically on all servers whenever an entity gets updated. You even can wrap such a cache refresh within a JTA transaction context to ensure all the caches get updated together. But that's a topic for an upcoming article.

Code Download

  • SpringHibernateEhcache.zip
  • About the Author

    Jacek Furmankiewicz is a Senior Java EE, Python, Oracle and MySQL developer at Radialpoint. He has 16 years of IT experience in writing enterprise software for a wide variety of industries.

    Page 2 of 2

    This article was originally published on August 9, 2010

    Enterprise Development Update

    Don't miss an article. Subscribe to our newsletter below.

    Thanks for your registration, follow us on our social networks to keep up-to-date