Chapter 40. Near Caching

Near caches are optional caches for Hot Rod Java client implementations that keep recently accessed data close to the user, providing faster access to data that is accessed frequently. This cache acts as a local Hot Rod client cache that is updated whenever a remote entry is retrieved via get or getVersioned operations.

In Red Hat JBoss Data Grid, near cache consistency is achieved by using remote events, which send notifications to clients when entries are modified or removed (refer to Remote Event Listeners (Hot Rod)). With Near Caching, local cache remains consistent with remote cache. Local entry is updated or invalidated whenever remote entry on the server is updated or removed. At the client level, near caching is configurable as either of the following:

Figure 40.1. Near Caching Architecture

Near caching can be enabled and disabled via configuration without making any changes to the Hot Rod Client application. To enable near caching, configure the near caching mode as INVALIDATED on the client, and optionally specify the number of entries to be kept in the cache.

Near cache mode is configured using the NearCacheMode enumeration.

The following example demonstrates how to configure near caching:

import org.infinispan.client.hotrod.configuration.ConfigurationBuilder;
import org.infinispan.client.hotrod.configuration.NearCacheMode;
…

ConfigurationBuilder builder = new ConfigurationBuilder();
builder.nearCache().mode(NearCacheMode.INVALIDATED).maxEntries(100);

A maximum size for the near cache must be provided, using the maxEntries(int maxEntries) method. In the above example this is defined to 100. When the maximum size is reached, near cached entries are evicted using a least-recently-used (LRU) algorithm. To define an unlimited near cache, a 0 or negative value may be passed in.

Near caches are implemented using Hot Rod Remote Events, and utilize clustered listeners for receiving events from across the cluster. Clustered listeners are installed on a single node within the cluster, with the remaining nodes sending events to the node on which the listeners are installed. It is therefore possible for a node running the near cache-backing clustered listener to fail. In this situation, another node takes over the clustered listener.

When the node running the clustered listener fails, a client failover event callback can be defined and invoked. For near caches, this callback and its implementation will clear the near cache, as during a failover events may be missed.

Refer to Clustered Listeners for more information.