The Second Level Cache in Hibernate: Settings and Configurations
A Hibernate Session is a transaction-level cache of persistent data. We can configure a cluster or JVM-level (SessionFactory-level) cache on a class-by-class and collection-by-collection basis. We can also plug in a clustered cache into Hibernate. At the time of providing cache we need to understand that when we are updating the persistence DB it will not automatically reflect on Cache.
Configuring CACHE in Hibernate
We need to tell Hibernate that which caching implementation we need to use. This we can accomplish by specifying the name of a class that implements org.hibernate.cache.CacheProviderusing the property hibernate.cache.provider_class. Hibernate comes bundled with a number of built-in integrations with open-source cache providers; additionally, we could implement your own and plug it in as outlined above. Prior to 3.2 Hibernate is defaulted to use EhCache as the default cache provider.
Cache mappings
The element of a class or collection mapping has the following form:
1.<cache2.usage="transactional|read-write|nonstrict-read-write|read-only" (1)3.region="RegionName" (2)4.include="all|non-lazy" (3)5./>
(1)
usage (required) specifies the caching strategy: transactional, read-write, nonstrict-read-write or read-only
(2)
region (optional, defaults to the class or collection role name) specifies the name of the second level cache region
(3)
include (optional, defaults to all) non-lazy specifies that properties of the entity mapped with lazy="true" may not be cached when attribute-level lazy fetching is enabled
Strategy: read only- Useful for data that is read frequently but never updated.
- It is Simple .
- Best performer among the all.
If application needs to read but never modify instances of a persistent class, a read-only cache may be used. This is the simplest and best performing strategy. It’s even perfectly safe for use in a cluster.
1.<class name="eg.Immutable" mutable="false">2.<cache usage="read-only"/>3.....4.</class>- Used when our data needs to be updated.
- It’s having more overhead than read-only caches.
- When Session.close() or Session.disconnect() is called the transaction should be completed in an environment where JTA is no used.
- It is never used if serializable transaction isolation level is required.
- In a JTA environment, for obtaining the JTA TransactionManager we must specify the propertyhibernate.transaction.manager_lookup_class.
- To use it in a cluster the cache implementation must support locking.
If the application needs to update data, a read-write cache might be appropriate. This cache strategy should never be used if serializable transaction isolation level is required. If the cache is used in a JTA environment, you must specify the property hibernate.transaction.manager_lookup_class, naming a strategy for obtaining the JTA TransactionManager. In other environments, you should ensure that the transaction is completed when Session.close() or Session.disconnect() is called. If you wish to use this strategy in a cluster, you should ensure that the underlying cache implementation supports locking. The built-in cache providers do not.
1.<class name="eg.Cat" .... >2.<cache usage="read-write"/>3.....4.<set name="kittens" ... >5.<cache usage="read-write"/>6.....7.</set>8.</class>- Needed if the application needs to update data rarely.
- we must specify hibernate.transaction.manager_lookup_class to use this in a JTA environment .
- The transaction is completed when Session.close() or Session.disconnect() is called In other environments (except JTA) .
If the application only occasionally needs to update data (ie. if it is extremely unlikely that two transactions would try to update the same item simultaneously) and strict transaction isolation is not required, 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, you should ensure that the transaction is completed when Session.close() or Session.disconnect() is called.
Strategy: transactional- It supports only transactional cache providers such as JBoss TreeCache.
- only used in JTA environment.
The transactional cache strategy provides support for fully transactional cache providers such as JBoss TreeCache. Such a cache may only be used in a JTA environment and you must specify hibernate.transaction.manager_lookup_class.
No comments:
Post a Comment