Related Documentation : Integrations : Using Ehcache with Hibernate : Configuring Hibernate Entities to use Second-Level Caching
Configuring Hibernate Entities to use Second-Level Caching
In addition to configuring the Hibernate second-level cache provider, Hibernate must also be told to enable caching for entities, collections, and queries. For example, the mapping entry for a domain object called, com.somecompany.someproject.domain.Country, looks something like this:
<hibernate-mapping>
<class
name="com.somecompany.someproject.domain.Country"
table="ut_Countries"
dynamic-update="false"
dynamic-insert="false"
>
...
</class>
</hibernate-mapping>
To enable caching for this domain object, you add the following element to its mapping entry:
<cache usage="read-write|nonstrict-read-write|read-only" />
For example:
<hibernate-mapping>
<class
name="com.somecompany.someproject.domain.Country"
table="ut_Countries"
dynamic-update="false"
dynamic-insert="false"
>
<cache usage="read-write" />
...
</class>
</hibernate-mapping>
You can also enable caching using the @Cache annotation as shown below.
@Entity
@Cache(usage = CacheConcurrencyStrategy.READ_WRITE)
public class Country {
...
}
Definition of the Different Cache Strategies
*read-only - Caches data that is never updated.
*nonstrict-read-write - Caches data that is sometimes updated without ever locking the cache. If concurrent access to an item is possible, this concurrency strategy makes no guarantee that the item returned from the cache is the latest version available in the database. Configure your cache timeout accordingly.
*read-write - Caches data that is sometimes updated while maintaining the semantics of “read committed” isolation level. If the database is set to “repeatable read,” this concurrency strategy almost maintains the semantics. Repeatable read isolation is compromised in the case of concurrent writes.
Copyright © 2010-2015 Software AG, Darmstadt, Germany.

Product Logo |   Feedback