SPI contract for Hibernate's second-level cache engine
Defines a context object that a
Specialized Region whose data is accessed directly (not requiring key/item wrapping, e.g.
A Region for cacheable domain data - entity, collection, natural-id.
Optional Region contract defining support for extra statistic information
Defines the responsibility for managing query result data caching in regards to a specific region.
Defines the contract for a cache region which will specifically be used to store query results.
Contract for a named "region".
Contract for building second level cache regions.
Wrapper for a
Responsible for building the TimestampsRegionAccessFactory to use for managing query results in regards to staleness of the underlying tables (sometimes called "query spaces" or "table spaces")
Allows cached queries to be keyed by enabled filters.
A key that identifies a particular query with bound parameter values.
RegionFactoryis the main integration contract that defines how Hibernate accesses the provider. It's main contract is the generation of
Regionreferences with the requested intent (what will be stored there). Generally a provider will integrate with Hibernate by: 1. implementing the contracts in
org.hibernate.cache.spi2. implementing the contracts in
org.hibernate.cache.spi.support3. a mix of (1) and (2) The first approach allows for more control of the set up, but also requires more to implement. The second approach tries to minimize the amount of work needed to integrate with caching providers to basically the
DomainDataStorageAccesscontracts which are basic read/write type abstractions of the underlying "cache" object - it is a nearly complete implementation aside from providing the proper "storage access" objects. Note: providers may also integrate with Hibernate via Hibernate's JCache support as defined by the `hibernate-jcache` module - no code involved aside from being a JCache implementation properly registered via the JCache spec.
Copyright © 2001-2018 Red Hat, Inc. All Rights Reserved.