Overview | Package | Class | Use | Tree | Deprecated | Index | Help
PREV CLASS NEXT CLASS | FRAMES NO FRAMES
SUMMARY: NESTED | FIELD | CONSTR | METHOD | DETAIL: FIELD | CONSTR | METHOD

## org.hibernate.cache
Interface CacheConcurrencyStrategy

All Known Implementing Classes:
  NonstrictReadWriteCache, ReadOnlyCache, ReadWriteCache, TransactionalCache

    public interface CacheConcurrencyStrategy

Implementors manage transactional access to cached data. Transactions pass in a timestamp indicating transaction start time. Two different implementation patterns are provided for.

- A transaction-aware cache implementation might be wrapped by a "synchronous" concurrency 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" concurrency 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.

In terms of entity caches, the expected call sequences are:

- DELETES : `lock(java.lang.Object, java.lang.Object)` -> `evict(java.lang.Object)` -> `release(java.lang.Object, org.hibernate.cache.CacheConcurrencyStrategy.SoftLock)`
- UPDATES : `lock(java.lang.Object, java.lang.Object)` -> `update(java.lang.Object, java.lang.Object, java.lang.Object, java.lang.Object)` -> `afterUpdate(java.lang.Object, java.lang.Object, java.lang.Object, org.hibernate.cache.CacheConcurrencyStrategy.SoftLock)`
- INSERTS : `insert(java.lang.Object, java.lang.Object, java.lang.Object)` -> `afterInsert(java.lang.Object, java.lang.Object, java.lang.Object)`

In terms of collection caches, all modification actions actually just invalidate the entry(s). The call sequence here is: `lock(java.lang.Object, java.lang.Object)` -> `evict(java.lang.Object)` -> `release(java.lang.Object, org.hibernate.cache.CacheConcurrencyStrategy.SoftLock)`

Note that, for an asynchronous cache, cache invalidation must be a two step process (lock->release, 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, this interface defines a three step process, to cater for both models.

Note that query result caching does not go through a concurrency strategy; they are managed directly against the underlying `cache regions`.

Nested Class Summary
`static interface` | `CacheConcurrencyStrategy.SoftLock` Marker interface, denoting a client-visible "soft lock" on a cached item.

Method Summary
`boolean` | `afterInsert(Object key, Object value, Object version)` Called after an item has been inserted (after the transaction completes), instead of calling release().
`boolean` | `afterUpdate(Object key, Object value, Object version, CacheConcurrencyStrategy.SoftLock lock)` Called after an item has been updated (after the transaction completes), instead of calling release().
`void` | `clear()` Evict all items from the cache immediately.
`void` | `destroy()` Clean up all resources.
`void` | `evict(Object key)` Called after an item has become stale (before the transaction completes).
`Object` | `get(Object key, long txTimestamp)` Attempt to retrieve an object from the cache.
`Cache` | `getCache()` Get the wrapped cache implementation
`String` | `getRegionName()` Get the cache region name
`boolean` | `insert(Object key, Object value, Object currentVersion)` Called after an item has been inserted (before the transaction completes), instead of calling evict().
`CacheConcurrencyStrategy.SoftLock` | `lock(Object key, Object version)` We are going to attempt to update/delete the keyed object.
`boolean` | `put(Object key, Object value, long txTimestamp, Object version, Comparator versionComparator, boolean minimalPut)` Attempt to cache an object, after loading from the database.
`void` | `release(Object key, CacheConcurrencyStrategy.SoftLock lock)` Called when we have finished the attempted update/delete (which may or may not have been successful), after transaction completion.
`void` | `remove(Object key)` Evict an item from the cache immediately (without regard for transaction isolation).
`void` | `setCache(Cache cache)` Set the underlying cache implementation.
`boolean` | `update(Object key, Object value, Object currentVersion, Object previousVersion)` Called after an item has been updated (before the transaction completes), instead of calling evict().

Method Detail

### get

    Object get(Object key,
               long txTimestamp)
               throws CacheException

  Attempt to retrieve an object from the cache. Mainly used in attempting to resolve entities/collections from the second level cache.

  Parameters:
    `key` -
    `txTimestamp` - a timestamp prior to the transaction start time
  Returns:
    the cached object or `null`
  Throws:
    `CacheException`

### put

    boolean put(Object key,
                Object value,
                long txTimestamp,
                Object version,
                Comparator versionComparator,
                boolean minimalPut)
                throws CacheException

  Attempt to cache an object, after loading from the database.

  Parameters:
    `key` -
    `value` -
    `txTimestamp` - a timestamp prior to the transaction start time
    `version` - the item version number
    `versionComparator` - a comparator used to compare version numbers
    `minimalPut` - indicates that the cache should avoid a put is the item is already cached
  Returns:
    `true` if the object was successfully cached
  Throws:
    `CacheException`

### lock

    CacheConcurrencyStrategy.SoftLock lock(Object key,
                                           Object version)
                                           throws CacheException

  We are going to attempt to update/delete the keyed object. This method is used by "asynchronous" concurrency strategies.

  The returned object must be passed back to release(), to release the lock. Concurrency strategies which do not support client-visible locks may silently return null.

  Parameters:
    `key` -
    `version` -
  Throws:
    `CacheException`

### evict

    void evict(Object key)
               throws CacheException

  Called after an item has become stale (before the transaction completes). This method is used by "synchronous" concurrency strategies.

  Throws:
    `CacheException`

### update

    boolean update(Object key,
                   Object value,
                   Object currentVersion,
                   Object previousVersion)
                   throws CacheException

  Called after an item has been updated (before the transaction completes), instead of calling evict(). This method is used by "synchronous" concurrency strategies.

  Throws:
    `CacheException`

### insert

    boolean insert(Object key,
                   Object value,
                   Object currentVersion)
                   throws CacheException

  Called after an item has been inserted (before the transaction completes), instead of calling evict(). This method is used by "synchronous" concurrency strategies.

  Throws:
    `CacheException`

### release

    void release(Object key,
                 CacheConcurrencyStrategy.SoftLock lock)
                 throws CacheException

  Called when we have finished the attempted update/delete (which may or may not have been successful), after transaction completion. This method is used by "asynchronous" concurrency strategies.

  Parameters:
    `key` -
  Throws:
    `CacheException`

### afterUpdate

    boolean afterUpdate(Object key,
                        Object value,
                        Object version,
                        CacheConcurrencyStrategy.SoftLock lock)
                        throws CacheException

  Called after an item has been updated (after the transaction completes), instead of calling release(). This method is used by "asynchronous" concurrency strategies.

  Throws:
    `CacheException`

### afterInsert

    boolean afterInsert(Object key,
                        Object value,
                        Object version)
                        throws CacheException

  Called after an item has been inserted (after the transaction completes), instead of calling release(). This method is used by "asynchronous" concurrency strategies.

  Throws:
    `CacheException`

### remove

    void remove(Object key)
                throws CacheException

  Evict an item from the cache immediately (without regard for transaction isolation).

  Parameters:
    `key` -
  Throws:
    `CacheException`

### clear

    void clear()
               throws CacheException

  Evict all items from the cache immediately.

  Throws:
    `CacheException`

### destroy

    void destroy()

  Clean up all resources.

### setCache

    void setCache(Cache cache)

  Set the underlying cache implementation.

  Parameters:
    `cache` -

### getRegionName

    String getRegionName()

  Get the cache region name

### getCache

    Cache getCache()

  Get the wrapped cache implementation

Overview | Package | Class | Use | Tree | Deprecated | Index | Help
PREV CLASS NEXT CLASS | FRAMES NO FRAMES
SUMMARY: NESTED | FIELD | CONSTR | METHOD | DETAIL: FIELD | CONSTR | METHOD