org.hibernate.cache.spi.access (Hibernate JavaDocs)
Date: 2012-04-05

Overview | Package | Class | Use | Tree | Deprecated | Index | Help
PREV PACKAGE NEXT PACKAGE | FRAMES NO FRAMES

## 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`.

Overview | Package | Class | Use | Tree | Deprecated | Index | Help
PREV PACKAGE NEXT PACKAGE | FRAMES NO FRAMES

Copyright © 2001-2012 Red Hat, Inc. All Rights Reserved.