Hibernate Caching Hibernate

What is Hibernate Caching?

Caching is every about request performance optimization and it sits between your application and the database to avoid the number of database hits as several as possible to give a better performance for presentation essential applications.

Caching is main to Hibernate as well which utilizes multilevel caching schemes as explained below:
hibernate_cache

First-level cache:

The first-level cache is the Session cache and is an optional cache through which all desires must pass. The Session object keeps an entity under its own power before commit it to the database.

If you subject multiple updates to an object, Hibernate tries to hold-up doing the update as long as possible to decrease the number of update SQL statements issued. If you secure the session, all the objects being cached are lost and either persisted or updated in the database.

Second-level cache:

Second level cache is an optional cache and first-level cache will always be consult before any attempt is made to locate an object in the second-level cache. The second-level cache can be configured on a per-class and per-collection basis and mainly in charge for caching objects across sessions.

Any third-party cache can be used with Hibernate. An org.hibernate.cache.CacheProvider line is provided, which must be implemented to supply Hibernate with a handle to the cache execution.

Query-level cache:

Hibernate also equipment a cache for query result sets that integrate directly with the second-level cache.

This is a possible feature and requires two additional physical cache regions that hold the cached query results and the timestamps when a table was last updated. This is only useful for queries that are run normally with the same parameters.

The Second Level Cache:

Hibernate uses first-level cache by defaulting and you have nothing to do to use first-level cache. Let's go straight to the optional second-level cache. Not all module benefit from caching, so it's important to be able to disable the second-level cache.

The Hibernate second-level cache is set up in two steps. First, you have to choose which concurrency strategy to use. After that, you configure cache termination and physical cache attributes using the cache contributor.

Concurrency strategies:

A concurrency strategy is a moderator which accountable for storing items of data in the cache and retrieving them from the cache. If you are going to permit a second-level cache, you will have to choose, for each constant class and collection, which cache concurrency strategy to use.

  • Transactional: Use this strategy for read-mostly data where it is critical to prevent stale data in concurrent transactions, in the rare case of an update.
  • Read-write: Again use this strategy for read-mostly data where it is critical to prevent stale data in concurrent transactions, in the rare case of an update.
  • Constrict-read-write: This strategy makes no guarantee of consistency between the cache and the database. Use this strategy if data hardly ever changes and a small likelihood of stale data is not of critical concern.
  • Read-only: A concurrency strategy suitable for data which never changes. Use it for reference data only.

If we are going to use second-level caching for our Employee class, let us add the mapping element necessary to tell Hibernate to cache Employee instances using read-write strategy.

The usage="read-write" attribute tells keep cover to use a read-write concurrency strategy for the define cache.

Cache provider:

Your next step following considering the concurrency strategies you will use for your cache applicant classes is to pick a cache provider. Hibernate forces you to choose a single cache contributor for the complete application.

S.N. Cache Name Description
1 EHCache It can cache in memory or on disk and clustered caching and it supports the optional Hibernate query result cache.
2 OSCache Supports caching to memory and disk in a single JVM, with a rich set of expiration policies and query cache support.
3 warmCache A cluster cache based on JGroups. It uses clustered invalidation but doesn't support the Hibernate query cache
4 JBoss Cache A fully transactional replicated clustered cache also based on the JGroups multicast library. It supports replication or invalidation, synchronous or asynchronous communication, and optimistic and pessimistic locking. The Hibernate query cache is supported

Every cache supplier is not friendly with every concurrency strategy. The following compatibility matrix will help you choose an appropriate combination.

Strategy/Provider Read-only Nonstrictread-write Read-write Transactional
EHCache X X X
OSCache X X X
SwarmCache X X
JBoss Cache X X

You will state a cache provider in hibernate.cfg.xml configuration file. We desire Hecate as our second-level cache provider:

Nowadays, you need to denote the properties of the cache regions. Hecate has its own formation file, ehcache.xml, which should be in the CLASSPATH of the function. A cache configuration in ehcache.xml for the Employee class may look like this:

That's it, now we have second-level caching enabled for the Employee class and Hibernate now hits the second-level cache whenever you navigate to an Employee or when you load an Employee by identifier.

You should analyze your all the classes and choose correct caching strategy for each of the classes. For a moment, second-level caching may downgrade the presentation of the application. So it is suggested to benchmark your application first without enabling caching and later on enable your well suited caching and check the performance. If caching is not recovering system performance then there is no point in enabling any type of caching.

The Query-level Cache:

To use the query cache, you must first start it using the hibernate.cache.use_query_cache="true" property in the configuration file. By setting this property to true, you make Hibernate create the essential caches in memory to hold the query and identifier sets.

Next, to use the query cache, you use the set Cacheable (Boolean) process of the Query class. For instance:

Hibernate also supports very fine-grained cache maintains through the concept of a cache section. A cache region is part of the cache that's given a name.

This code uses the method to tell Hibernate to store and look for the query in the employee area of the cache.

All rights reserved © 2018 Wisdom IT Services India Pvt. Ltd DMCA.com Protection Status

Hibernate Topics