Hibernate - Caching

Ref:- https://docs.jboss.org/hibernate/orm/4.0/devguide/en-US/html/ch06.html

The query cache

If you have queries that run over and over, with the same parameters, query caching provides performance gains.
Caching introduces overhead in the area of transactional processing. For example, if you cache results of a query against an object, Hibernate needs to keep track of whether any changes have been committed against the object, and invalidate the cache accordingly. In addition, the benefit from caching query results is limited, and highly dependent on the usage patterns of your application. For these reasons, Hibernate disables the query cache by default.

Procedure 6.1. Enabling the query cache

1. Set the hibernate.cache.use_query_cache property to true.
   This setting creates two new cache regions:
   
   • org.hibernate.cache.internal.StandardQueryCache holds the cached query results.
   • org.hibernate.cache.spi.UpdateTimestampsCache holds timestamps of the most recent updates to queryable tables. These timestamps validate results served from the query cache.
2. Adjust the cache timeout of the underlying cache region
   If you configure your underlying cache implementation to use expiry or timeouts, set the cache timeout of the underlying cache region for the UpdateTimestampsCache to a higher value than the timeouts of any of the query caches. It is possible, and recommended, to set the UpdateTimestampsCache region never to expire. To be specific, a LRU (Least Recently Used) cache expiry policy is never appropriate.
3. Enable results caching for specific queries
   Since most queries do not benefit from caching of their results, you need to enable caching for individual queries, e ven after enabling query caching overall. To enable results caching for a particular query, call org.hibernate.Query.setCacheable(true). This call allows the query to look for existing cache results or add its results to the cache when it is executed.

The query cache does not cache the state of the actual entities in the cache. It caches identifier values and results of value type. Therefore, always use the query cache in conjunction with the second-level cache for those entities which should be cached as part of a query result cache.

6.1.1. Query cache regions

For fine-grained control over query cache expiration policies, specify a named cache region for a particular query by calling Query.setCacheRegion().

Example 6.1. Method setCacheRegion

List blogs = sess.createQuery("from Blog blog where blog.blogger = :blogger")
        .setEntity("blogger", blogger)
        .setMaxResults(15)
        .setCacheable(true)
        .setCacheRegion("frontpages")
        .list();

To force the query cache to refresh one of its regions and disregard any cached results in the region, callorg.hibernate.Query.setCacheMode(CacheMode.REFRESH). In conjunction with the region defined for the given query, Hibernate selectively refreshes the results cached in that particular region. This is much more efficient than bulk eviction of the region via org.hibernate.SessionFactory.evictQueries().

6.2. Second-level cache providers

Hibernate is compatible with several second-level cache providers. None of the providers support all of Hibernate's possible caching strategies. Section 6.2.3, “Second-level cache providers for Hibernate” lists the providers, along with their interfaces and supported caching strategies. For definitions of caching strategies, see Section 6.2.2, “Caching strategies”.

6.2.1. Configuring your cache providers

You can configure your cache providers using either annotations or mapping files.

Entities

By default, entities are not part of the second-level cache, and their use is not recommended. If you absolutely must use entities, set the shared-cache-mode element in persistence.xml, or use propertyjavax.persistence.sharedCache.mode in your configuration. Use one of the values in Table 6.1, “Possible values for Shared Cache Mode”.

Table 6.1. Possible values for Shared Cache Mode

Value	Description
ENABLE_SELECTIVE	Entities are not cached unless you explicitly mark them as cachable. This is the default and recommended value.
DISABLE_SELECTIVE	Entities are cached unless you explicitly mark them as not cacheable.
ALL	All entities are always cached even if you mark them as not cacheable.
NONE	No entities are cached even if you mark them as cacheable. This option basically disables second-level caching.

Set the global default cache concurrency strategy The cache concurrency strategy with thehibernate.cache.default_cache_concurrency_strategy configuration property. See Section 6.2.2, “Caching strategies” for possible values.

Note

When possible, define the cache concurrency strategy per entity rather than globally. Use the@org.hibernate.annotations.Cache annotation.

Example 6.2. Configuring cache providers using annotations

@Entity 
@Cacheable
@Cache(usage = CacheConcurrencyStrategy.NONSTRICT_READ_WRITE)
public class Forest { ... }

You can cache the content of a collection or the identifiers, if the collection contains other entities. Use the@Cache annotation on the Collection property.
@Cache can take several attributes.

Attributes of @Cache annotation

usage

The given cache concurrency strategy, which may be:

• NONE
• READ_ONLY
• NONSTRICT_READ_WRITE
• READ_WRITE
• TRANSACTIONAL

region

The cache region. This attribute is optional, and defaults to the fully-qualified class name of the class, or the qually-qualified role name of the collection.

include

Whether or not to include all properties.. Optional, and can take one of two possible values.

• A value of all includes all properties. This is the default.
• A value of non-lazy only includes non-lazy properties.

Example 6.3. Configuring cache providers using mapping files

<cache
    usage="transactional"
    region="RegionName"
    include="all"
/>

Just as in the Example 6.2, “Configuring cache providers using annotations”, you can provide attributes in the mapping file. There are some specific differences in the syntax for the attributes in a mapping file.

usage

The caching strategy. This attribute is required, and can be any of the following values.

• transactional
• read-write
• nonstrict-read-write
• read-only

region

The name of the second-level cache region. This optional attribute defaults to the class or collection role name.

include

Whether properties of the entity mapped with lazy=true can be cached when attribute-level lazy fetching is enabled. Defaults to all and can also be non-lazy.

Instead of <cache>, you can use <class-cache> and <collection-cache> elements in hibernate.cfg.xml.

6.2.2. Caching strategies

read-only

A read-only cache is good for data that needs to be read often but not modified. It is simple, performs well, and is safe to use in a clustered environment.

nonstrict read-write

Some applications only rarely need to modify data. This is the case if two transactions are unlikely to try to update the same item simultaneously. In this case, you do not need strict transaction isolation, and a nonstrict-read-write cache might be appropriate. If the cache is used in a JTA environment, you must specify hibernate.transaction.manager_lookup_class. In other environments, ensore that the transaction is complete before you call Session.close() or Session.disconnect().

read-write

A read-write cache is appropriate for an application which needs to update data regularly. Do not use a read-write strategy if you need serializable transaction isolation. In a JTA environment, specify a strategy for obtaining the JTA TransactionManager by setting the propertyhibernate.transaction.manager_lookup_class. In non-JTA environments, be sure the transaction is complete before you call Session.close() or Session.disconnect().

Note

To use the read-write strategy in a clustered environment, the underlying cache implementation must support locking. The build-in cache providers do not support locking.

transactional

The transactional cache strategy provides support for transactional cache providers such as JBoss TreeCache. You can only use such a cache in a JTA environment, and you must first specifyhibernate.transaction.manager_lookup_class.

6.2.3. Second-level cache providers for Hibernate

Cache	Interface	Supported strategies
HashTable (testing only)		read-only nontrict read-write read-write
EHCache		read-only nontrict read-write read-write
OSCache		read-only nontrict read-write read-write
SwarmCache		read-only nontrict read-write
JBoss Cache 1.x		read-only transactional
JBoss Cache 2.x		read-only transactional

6.3. Managing the cache

6.3.1. Moving items into and out of the cache

Actions that add an item to internal cache of the Session

Saving or updating an item

• save()
• update()
• saveOrUpdate()

Retrieving an item

• load()
• get()
• list()
• iterate()
• scroll()

Syncing or removing a cached item

The state of an object is synchronized with the database when you call method flush(). To avoid this synchronization, you can remove the object and all collections from the first-level cache with the evict()method. To remove all items from the Session cache, use method Session.clear().

Example 6.4. Evicting an item from the first-level cache

ScrollableResult cats = sess.createQuery("from Cat as cat").scroll(); //a huge result set
while ( cats.next() ) {
    Cat cat = (Cat) cats.get(0);
    doSomethingWithACat(cat);
    sess.evict(cat);
}

Determining whether an item belongs to the Session cache

The Session provides a contains() method to determine if an instance belongs to the session cache.

Example 6.5. Second-level cache eviction

You can evict the cached state of an instance, entire class, collection instance or entire collection role, using methods of SessionFactory.

sessionFactory.getCache().containsEntity(Cat.class, catId); // is this particular Cat currently in the cache

sessionFactory.getCache().evictEntity(Cat.class, catId); // evict a particular Cat

sessionFactory.getCache().evictEntityRegion(Cat.class);  // evict all Cats

sessionFactory.getCache().evictEntityRegions();  // evict all entity data

sessionFactory.getCache().containsCollection("Cat.kittens", catId); // is this particular collection currently in the cache

sessionFactory.getCache().evictCollection("Cat.kittens", catId); // evict a particular collection of kittens

sessionFactory.getCache().evictCollectionRegion("Cat.kittens"); // evict all kitten collections

sessionFactory.getCache().evictCollectionRegions(); // evict all collection data

6.3.1.1. Interactions between a Session and the second-level cache

The CacheMode controls how a particular session interacts with the second-level cache.

CacheMode.NORMAL	reads items from and writes them to the second-level cache.
CacheMode.GET	reads items from the second-level cache, but does not write to the second-level cache except to update data.
CacheMode.PUT	writes items to the second-level cache. It does not read from the second-level cache. It bypasses the effect of hibernate.cache.use_minimal_puts and forces a refresh of the second-level cache for all items read from the database.

6.3.1.2. Browsing the contents of a second-level or query cache region

After enabling statistics, you can browse the contents of a second-level cache or query cache region.

Procedure 6.2. Enabling Statistics

1. Set hibernate.generate_statistics to true.
2. Optionally, set hibernate.cache.use_structured_entries to true, to cause Hibernate to store the cache entries in a human-readable format.

Example 6.6. Browsing the second-level cache entries via the Statistics API

Map cacheEntries = sessionFactory.getStatistics()
        .getSecondLevelCacheStatistics(regionName)
        .getEntries();