Package org.hibernate.cache.spi.access

Defines contracts for transactional and concurrent access to cached entity and collection data.

See:
Description

Interface Summary

CollectionRegionAccessStrategy	Contract for managing transactional and concurrent access to cached collection data.
EntityRegionAccessStrategy	Contract for managing transactional and concurrent access to cached entity data.
NaturalIdRegionAccessStrategy	Contract for managing transactional and concurrent access to cached naturalId data.
RegionAccessStrategy
SoftLock	Marker object for use by synchronous concurrency strategies

Enum Summary

AccessType

The types of access strategies available.

Exception Summary

UnknownAccessTypeException

Package org.hibernate.cache.spi.access Description

Defines contracts for transactional and concurrent access to cached entity and collection data. Transactions pass in a timestamp indicating transaction start time which is then used to protect against concurrent access (exactly how that occurs is based on the actual access-strategy impl used). Two different implementation patterns are provided for:

• A transaction-aware cache implementation might be wrapped by a synchronous access strategy, where updates to the cache are written to the cache inside the transaction.
• A non-transaction-aware cache would be wrapped by an asynchronous access strategy, where items are merely "soft locked" during the transaction and then updated during the "after transaction completion" phase; the soft lock is not an actual lock on the database row - only upon the cached representation of the item.

The asynchronous access strategies are: read-only, read-write and nonstrict-read-write. The only synchronous access strategy is transactional.

Note that, for an asynchronous cache, cache invalidation must be a two step process (lock->unlock or lock->afterUpdate), since this is the only way to guarantee consistency with the database for a nontransactional cache implementation. For a synchronous cache, cache invalidation is a single step process (evict or update). Hence, these contracts (EntityRegionAccessStrategy and CollectionRegionAccessStrategy) define a three step process to cater for both models (see the individual contracts for details).

Note that query result caching does not go through an access strategy; those caches are managed directly against the underlying QueryResultsRegion.