Class JCacheCache

java.lang.Object
org.springframework.cache.support.AbstractValueAdaptingCache
org.springframework.cache.jcache.JCacheCache
All Implemented Interfaces:
Cache
public class JCacheCache extends AbstractValueAdaptingCache
Cache implementation on top of a javax.cache.Cache instance.

Note: This class has been updated for JCache 1.0, as of Spring 4.0.

Since:
3.2
Author:
Juergen Hoeller, Stephane Nicoll
See Also:

  • Constructor Details

    • JCacheCache

      public JCacheCache(javax.cache.Cache<Object,Object> jcache)
      Create a JCacheCache instance.
      Parameters:
      jcache - backing JCache Cache instance

    • JCacheCache

      public JCacheCache(javax.cache.Cache<Object,Object> jcache, boolean allowNullValues)
      Create a JCacheCache instance.
      Parameters:
      jcache - backing JCache Cache instance
      allowNullValues - whether to accept and convert null values for this cache

  • Method Details

    • getName

      public final String getName()
      Description copied from interface: Cache
      Return the cache name.

    • getNativeCache

      public final javax.cache.Cache<Object,Object> getNativeCache()
      Description copied from interface: Cache
      Return the underlying native cache provider.

    • lookup

      protected @Nullable Object lookup(Object key)
      Description copied from class: AbstractValueAdaptingCache
      Perform an actual lookup in the underlying store.
      Specified by:
      lookup in class AbstractValueAdaptingCache
      Parameters:
      key - the key whose associated value is to be returned
      Returns:
      the raw store value for the key, or null if none

    • get

      public <T> @Nullable T get(Object key, Callable<T> valueLoader)
      Description copied from interface: Cache
      Return the value to which this cache maps the specified key, obtaining that value from valueLoader if necessary. This method provides a simple substitute for the conventional "if cached, return; otherwise create, cache and return" pattern.

      If possible, implementations should ensure that the loading operation is synchronized so that the specified valueLoader is only called once in case of concurrent access on the same key.

      If the valueLoader throws an exception, it is wrapped in a Cache.ValueRetrievalException

      Parameters:
      key - the key whose associated value is to be returned
      Returns:
      the value to which this cache maps the specified key
      See Also:

    • put

      public void put(Object key, @Nullable Object value)
      Description copied from interface: Cache
      Associate the specified value with the specified key in this cache.

      If the cache previously contained a mapping for this key, the old value is replaced by the specified value.

      Actual registration may be performed in an asynchronous or deferred fashion, with subsequent lookups possibly not seeing the entry yet. This may for example be the case with transactional cache decorators. Use Cache.putIfAbsent(Object, Object) for guaranteed immediate registration.

      If the cache is supposed to be compatible with CompletableFuture and reactive interactions, the put operation needs to be effectively non-blocking, with any backend write-through happening asynchronously. This goes along with a cache implemented and configured to support Cache.retrieve(Object) and Cache.retrieve(Object, Supplier).

      Parameters:
      key - the key with which the specified value is to be associated
      value - the value to be associated with the specified key
      See Also:

    • putIfAbsent

      public @Nullable Cache.ValueWrapper putIfAbsent(Object key, @Nullable Object value)
      Description copied from interface: Cache
      Atomically associate the specified value with the specified key in this cache if it is not set already.

      This is equivalent to: 

      ValueWrapper existingValue = cache.get(key);
if (existingValue == null) {
    cache.put(key, value);
}
return existingValue;
      except that the action is performed atomically. While all out-of-the-box CacheManager implementations are able to perform the put atomically, the operation may also be implemented in two steps, for example, with a check for presence and a subsequent put, in a non-atomic way. Check the documentation of the native cache implementation that you are using for more details.

      The default implementation delegates to Cache.get(Object) and Cache.put(Object, Object) along the lines of the code snippet above.

      Parameters:
      key - the key with which the specified value is to be associated
      value - the value to be associated with the specified key
      Returns:
      the value to which this cache maps the specified key (which may be null itself), or also null if the cache did not contain any mapping for that key prior to this call. Returning null is therefore an indicator that the given value has been associated with the key.
      See Also:

    • evict

      public void evict(Object key)
      Description copied from interface: Cache
      Evict the mapping for this key from this cache if it is present.

      Actual eviction may be performed in an asynchronous or deferred fashion, with subsequent lookups possibly still seeing the entry. This may for example be the case with transactional cache decorators. Use Cache.evictIfPresent(Object) for guaranteed immediate removal.

      If the cache is supposed to be compatible with CompletableFuture and reactive interactions, the evict operation needs to be effectively non-blocking, with any backend write-through happening asynchronously. This goes along with a cache implemented and configured to support Cache.retrieve(Object) and Cache.retrieve(Object, Supplier).

      Parameters:
      key - the key whose mapping is to be removed from the cache
      See Also:

    • evictIfPresent

      public boolean evictIfPresent(Object key)
      Description copied from interface: Cache
      Evict the mapping for this key from this cache if it is present, expecting the key to be immediately invisible for subsequent lookups.

      The default implementation delegates to Cache.evict(Object), returning false for not-determined prior presence of the key. Cache providers and in particular cache decorators are encouraged to perform immediate eviction if possible (for example, in case of generally deferred cache operations within a transaction) and to reliably determine prior presence of the given key.

      Parameters:
      key - the key whose mapping is to be removed from the cache
      Returns:
      true if the cache was known to have a mapping for this key before, false if it did not (or if prior presence could not be determined)
      See Also:

    • clear

      public void clear()
      Description copied from interface: Cache
      Clear the cache through removing all mappings.

      Actual clearing may be performed in an asynchronous or deferred fashion, with subsequent lookups possibly still seeing the entries. This may for example be the case with transactional cache decorators. Use Cache.invalidate() for guaranteed immediate removal of entries.

      If the cache is supposed to be compatible with CompletableFuture and reactive interactions, the clear operation needs to be effectively non-blocking, with any backend write-through happening asynchronously. This goes along with a cache implemented and configured to support Cache.retrieve(Object) and Cache.retrieve(Object, Supplier).

      See Also:

    • invalidate

      public boolean invalidate()
      Description copied from interface: Cache
      Invalidate the cache through removing all mappings, expecting all entries to be immediately invisible for subsequent lookups.
      Returns:
      true if the cache was known to have mappings before, false if it did not (or if prior presence of entries could not be determined)
      See Also: