Chapter 4. Cache Modes

Using Red Hat JBoss Data Grid’s local mode instead of a map provides a number of benefits.

Caches offer features that are unmatched by simple maps, such as:

JBoss Data Grid is built around a high performance, read-based data container that uses techniques such as optimistic and pessimistic locking to manage lock acquisitions.

JBoss Data Grid also uses compare-and-swap and other lock-free algorithms, resulting in high throughput multi-CPU or multi-core environments. Additionally, JBoss Data Grid’s Cache API extends the JDK's ConcurrentMap, resulting in a simple migration process from a map to JBoss Data Grid.

A local cache can be added to any cache container in both Library Mode and Remote Client-Server Mode. The following example demonstrates how to add the local-cache element.

<cache-container name="local"
                 default-cache="default"
                 statistics="true">
    <local-cache name="default"
        statistics="true">
        <!-- Additional configuration information here -->
    </local-cache>
</cache-container>

<cache-container name="local"
                 default-cache="default"
                 statistics="true">
    <local-cache name="default"
        statistics="true">
        <!-- Additional configuration information here -->
    </local-cache>
</cache-container>

The local-cache element specifies information about the local cache used with the cache container using the following parameters: . The name parameter specifies the name of the local cache to use. . If statistics are enabled at the container level, per-cache statistics can be selectively disabled for caches that do not require monitoring by setting the statistics attribute to false.

Local and clustered caches are able to coexist in the same cache container, however where the container is without a <transport/> it can only contain local caches. The container used in the example can only contain local caches as it does not have a <transport/>.

The cache interface extends the ConcurrentMap and is compatible with multiple cache systems.

Red Hat JBoss Data Grid offers the following clustered modes:

The clustered modes can be further configured to use synchronous or asynchronous transport for network communications.

When a clustered mode (such as invalidation, replication or distribution) is used, data is propagated to other nodes in either a synchronous or asynchronous manner.

If synchronous mode is used, the sender waits for responses from receivers before allowing the thread to continue, whereas asynchronous mode transmits data but does not wait for responses from other nodes in the cluster to continue operations.

JBoss Data Grid clusters are configured to use synchronous operations by default.

Asynchronous mode prioritizes speed over consistency, which is ideal for use cases such as HTTP session replications with sticky sessions enabled. Such a session (or data for other use cases) is always accessed on the same cluster node, unless this node fails. If data consistency is required for your use case, you should use synchronous operations.

Additionally, it is not possible for JBoss Data Grid nodes to determine if asynchronous operations succeed because receiving nodes do not send status for operations back to the originating nodes.

In JBoss Data Grid, distributed and replicated caches are represented by the distributed-cache and replicated-cache elements.

Each of these elements contains a mode property, the value of which can be set to SYNC for synchronous, which is the default, or ASYNC for asynchronous communications.

<replicated-cache name="default"
                  statistics="true"
                  mode="ASYNC">
                 <!-- Additional configuration information here -->
</replicated-cache>

<replicated-cache name="default"
                  statistics="true"
                  mode="ASYNC">
                 <!-- Additional configuration information here -->
</replicated-cache>