19.2. The Second Level Cache
Sessionis a transaction-level cache of persistent data. It is possible to configure a cluster or JVM-level (
SessionFactory-level) cache on a class-by-class and collection-by-collection basis. You may even plug in a clustered cache. Be careful. Caches are never aware of changes made to the persistent store by another application (though they may be configured to regularly expire cached data).
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 (listed below); additionally, you could implement your own and plug it in as outlined above. Note that versions prior to 3.2 defaulted to use EhCache as the default cache provider; that is no longer the case as of 3.2.
Table 19.1. Cache Providers
|Cache||Provider class||Type||Cluster Safe||Query Cache Supported|
|Hashtable (not intended for production use)|| ||memory||yes|
|EHCache|| ||memory, disk||yes|
|OSCache|| ||memory, disk||yes|
|SwarmCache|| ||clustered (ip multicast)||yes (clustered invalidation)|
|JBoss TreeCache|| ||clustered (ip multicast), transactional||yes (replication)||yes (clock sync req.)|
19.2.1. Cache mappings
<cache>element of a class or collection mapping has the following form:
<cache usage="transactional|read-write|nonstrict-read-write|read-only" region="RegionName" include="all|non-lazy" />
usage(required) specifies the caching strategy:
region(optional, defaults to the class or collection role name) specifies the name of the second level cache region
include(optional, defaults to
non-lazyspecifies that properties of the entity mapped with
lazy="true"may not be cached when attribute-level lazy fetching is enabled
usageattribute specifies a cache concurrency strategy.