Cache Configuration

Introduction

A JSLEE deployment may require the caching of data in local memory for performant data lookup based on a unique key. Performance-focused cache lookups within the JSLEE are used for fast access to most recently used data records where source data is stored in a separate system and must be accessed in real time, but may be cached in-memory locally to the JSLEE.

Caches are implemented using the Java Caffeine high performance caching library which are backed by structured data in a local (or co-located) databases, on disk, or within another REST or SOAP service.

Data storage is often constrained by memory requirement, so caches can be configured to use either size-based evictions (with least recently used data dropped from memory), or time-based expiration. Stale data may be automatically reloaded from the underlying data source after a specified duration of in-cache use.

Internally, the JSLEE is developed with a standardised cache solution which supports all the above general scenarios through a combination of built-in service logic and per-site configuration.

To provide this flexibility, cache control is configurable within the JSLEE server configuration file, on a per-service basis.

Configuration

Where a cache is configured through JSON object, it must be given a name, provider, and provider configuration. Additional configuration may be required depending on provider type and purpose.

A basic configuration set up may look like:

{
    "name": "number_portability",
    "provider-class": "nz.co.nsquared.slee.cache.JDBCProvider",
    "provider-config": {
       // Database source-specific configuration
    },
    "cache-manager-config": {
       // Caffeine-related configuration for cache management
    }
}

Cache Names

Each cache must have a name, as the name of each cache is how the service internally will identify and gain access to it.

Cache names need not be unique across services, however two caches should not have the same name if they are to not be used for the same purpose. For example, if two Diameter relay agent services are expected to use two distinct caches for MSISDN lookup, the two cache definitions should be uniquely named. However if both Diameter relay agents should use the same data source and cache, then they may (and indeed, should) use the same name - otherwise two in-memory caches will duplicate the same data, and double memory usage unnecessarily.

Cache Provider

Each configured cache must define how the data source for cache data is accessed. The following cache providers are available in the JSLEE.

• The JDBC Provider caches look up cache values by querying a JDBC datasource with a provided lookup query and key.
  A cache backed by a JDBC datasource can be created using:

"provider-class": "nz.co.nsquared.slee.cache.JDBCProvider"

Cache Manager Config

Each cache must have cache manager configuration defined. Configuration options can be set using the Caffeine cache specification as documented in the Caffeine JavaDoc where each spec value is a JSON key in the cache-manager-config JSON object.

Basic cache manager configuration may look like:

{
  "cache-manager-config": {
      "maximumSize": 10000,
      "expireAfterWrite": "10m"
  }
}

Where maximumSize is the maximum number of entries in the cache, and expireAfterWrite determines how long before a cache entry is expired (and evicted) since it was first read from the backing store.