Used in: caching-schemes.


The near-scheme defines a two tier cache consisting of a front-tier which caches a subset of a back-tier cache. The front-tier is generally a fast, size limited cache, while the back-tier is slower, but much higher capacity. A typical deployment might use a local-scheme for the front-tier, and a distributed-scheme for the back-tier. The result is that a portion of a large partitioned cache will be cached locally in-memory allowing for very fast read access. See the services overview for a more detailed description of near caches, and the near cache sample for an example of a near cache configurations.


The near scheme is implemented by the class.

Front-tier Invalidation

Specifying an invalidation-strategy defines a strategy that is used to keep the front tier of the near cache in sync with the back tier. Depending on that strategy a near cache is configured to listen to certain events occurring on the back tier and automatically update (or invalidate) the front portion of the near cache.


The following table describes the elements you can define within the near-scheme element.

Element Required/Optional Description
<scheme-name> Optional Specifies the scheme's name. The name must be unique within a configuration file.
<scheme-ref> Optional Specifies the name of another scheme to inherit from.
<class-name> Optional Specifies a custom implementation of the near cache.

Any custom implementation must extend the class and declare the exact same set of public constructors.
<init-params> Optional Specifies initialization parameters, for use in custom near cache implementations which implement the interface.
<listener> Optional Specifies an implementation of a com.tangosol.util.MapListener which will be notified of events occurring on the cache.
<front-scheme> Required Specifies the cache-scheme to use in creating the front-tier cache.

Legal values are:

The eviction policy of the front-scheme defines which entries will be cached locally.
For example:

<back-scheme> Required Specifies the cache-scheme to use in creating the back-tier cache.

Legal values are:

For example:

<invalidation-strategy> Optional Specifies the strategy used keep the front-tier in-sync with the back-tier.

Please see for more details.

Legal values are:

  • none - 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. The worst case performance is identical to a standard Distributed cache.
  • present - instructs the near cache to listen to the back map events related only to the items currently present in the front map.
    This strategy works best when cluster nodes have sticky data access patterns (for example, HTTP session management with a sticky load balancer).
  • all - instructs the near cache to listen to all back map events.
    This strategy is optimal for read-heavy access patterns where there is significant overlap between the front caches on each cluster member.
  • auto - instructs the near cache to switch between present and all strategies automatically based on the cache statistics.

Default value is auto.

<autostart> Optional The autostart element is intended to be used by cache servers (i.e. It specifies whether or not the cache services associated with this cache scheme should be automatically started at a cluster node.

Legal values are true or false.

Default value is false.