Oracle® Fusion Middleware .NET API Reference for Oracle Coherence
12c (12.2.1.4.0)
E90869-02
ICache implementation that wraps two caches - a front cache (assumed to be "inexpensive" and probably "incomplete") and a back cache (assumed to be "complete" and "correct", but more "expensive") - using a read-through/write-through approach.

Namespace: Tangosol.Net.Cache
Assembly: Coherence (in Coherence.dll) Version: 12.2.1.4014 (12.2.1.4014)

Syntax

C#
public class CompositeCache : ICache, 
	IDictionary, ICollection, IEnumerable, ICacheStatistics, IDisposable

Remarks

If the back cache implements IObservableCache interface, the CompositeCache provides four different strategies of invalidating the front cache entries that have changed by other processes in the back cache:

  • ListenNone strategy instructs the cache not to listen for invalidation events at all. This is the best choice for raw performance and scalability when business requirements permit the use of data which might not be absolutely current. Freshness of data can be guaranteed by use of a sufficiently brief eviction policy for the front cache.
  • ListenPresent strategy instructs the CompositeCache to listen to the back cache events related only to the items currently present in the front cache. This strategy works best when each instance of a front cache contains distinct subset of data relative to the other front cache instances (e.g. sticky data access patterns).
  • ListenAll strategy instructs the CompositeCache to listen to all back cache events. This strategy is optimal for read-heavy tiered access patterns where there is significant overlap between the different instances of front caches.
  • ListenAuto strategy instructs the CompositeCache implementation to switch automatically between ListenPresent and ListenAll strategies based on the cache statistics.
  • ListenLogical strategy instructs the CompositeCache to listen to all back map events that are not synthetic. A synthetic event could be emitted as a result of eviction or expiration. With this invalidation stategy, it is possible for the front map to contain cache entries that have been synthetically removed from the back (though any subsequent re-insertion will cause the corresponding entries in the front map to be invalidated).

The front cache implementation is assumed to be thread safe; additionally any modifications to the front cache are allowed only after the corresponding lock is acquired against the CacheControl property.

Note:null values are not cached in the front cache and therefore this implementation is not optimized for caches that allow null values to be stored.

Inheritance Hierarchy

System..::..Object
  Tangosol.Net.Cache..::..CompositeCache
    Tangosol.Net.Cache..::..NearCache

See Also