near-scheme

`near-scheme`

Used in: caching-schemes.

Description

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.

Implementation

The near scheme is implemented by the ${xhtml} 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.

Elements

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 ${xhtml} 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 ${xhtml} (or ${xhtml} for C++) interface.
`<listener>`	Optional	Specifies an implementation of a ${xhtml} (or ${xhtml} for C++) 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: `local-scheme` `external-scheme` `paged-external-scheme` `class-scheme` 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: `distributed-scheme` `replicated-scheme` `optimistic-scheme` `local-scheme` `external-scheme` `paged-external-scheme` `class-scheme` `remote-cache-scheme` For example:
`<invalidation-strategy>`	Optional	Specifies the strategy used keep the front-tier in-sync with the back-tier. Please see ${xhtml} 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 (that is, ${xhtml}). 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`.