IBM provides in-memory cache services called Dynacache, which are replicated across multiple instances in a clustered environment. The cache is stored in JVM heap memory. The cache, being in heap, makes it extremely fast compared to any external caching solutions. It has the disk offload mechanism where cache content may overflow to the disk based on LRU and user-specified cache entry priority number. Even though the cache is maintained in heap memory, it can a survive server restart. When the FlushToDIskOnStop property is enabled, it offloads the cache to disk and reloads when the server boots up again. The replication to other instances in a clustered environment happens using Distributed Replication Services (DRS).

The WebSphere Application Server provides cache instances to configure Dynacache. There are two types of cache instances — servlet cache instances and object cache instances. The servlet cache instances are for servlets, jsps, struts tiles, etc, whereas object cache instances are used for Java objects. The instances are bound to the JNDI namespace. The Distributed Map and DistributedObjectCache are simple interfaces for the Dynacache. 

We will explore object cache instances with the Spring caching mechanism. Spring uses annotations to avoid all the boilerplate code for caching. The cache is handled by cache manager in spring. 

Spring Boot also introduced auto configuration which made it easy to work on any spring application. We can auto-configure the Dynacache implementation and remove the cache manager coding from the spring application. The dynacache implementation is bundled in a jar file and when introduced in class path will auto configure the dynacache in the application. 

The following properties in application.properties will configure the dynacache in the application. 

spring.cache.cache-names=visiondata-24h,visiondata-4h,visiondata-1h,visiondata-30m,visiondata-no-expiry,visiondata-update-cache
## cache name used with @Caching
spring.cache.dynacache[0].cache-name=visiondata-update-cache
## JNDI name for the Dynacache
spring.cache.dynacache[0].jndi=cache/visionData-update-cache
## Time in minutes for entries in cache
spring.cache.dynacache[0].ttl=30

spring.cache.dynacache[1].cache-name=visiondata-24h
spring.cache.dynacache[1].jndi=cache/visionData-update-cache
spring.cache.dynacache[1].ttl=1440

The cache in Spring application is enabled using

 @EnableCaching 

The Spring Boot Auto configure class requires a ComponentScan to “com.pcl.core.cache” because the auto Configuration classes in the dynacache-1.0 jar are present in “com.pcl.core.cache” folder.

@SpringBootApplication
@ComponentScan(basePackages = {"com.pcl.core.cache” })
public class Application extends SpringBootServletInitializer  {

    @Override
    protected SpringApplicationBuilder configure(SpringApplicationBuilder application) {
        return application.sources(Application.class); 
    }   
}

The object cache instances can be configured in the following ways in Application Server -

WebSphere Liberty:

<distributedMap id="services/cache/ccm"  jndiName="cache/visiondata-update-cache“></distributedMap>

In WebSphere Application Server it can be configured from the admin console.

The key object pairs are stored in DistributedMaps (with names visiondata-update-cache, visiondata-24h) obtained from the object cache instance visiondata-update-cache.

You can add the jar as a dependency in your spring boot application. 

 compile (group:"com.pcl", name:"exscale", version:"1.0", changing: true) 

Spring cache can be used in the application as 

@Service
@CacheConfig(cacheNames="visiondata-24h")
public class AgencyServiceImpl implements AgencyService {
...
@Cacheable
public List<Agency> getAgencies(Map<String, String> propertyNameValues) throws DAOException {
...
}
    ...
}

A brief insight into the dynacache-1.0 jar:

In the auto-configuration jar, the DistributedMap is encapsulated in WASCache implementing org.springframework.cache.Cache. The cache manager stores the list of WASCache. It uses org.springframework.cache.support.AbstractCacheManager to build the cache manager from the list of WASCache. 

A lookup to the object instance JNDI is an expensive operation, so we keep the distributed map obtained from the lookup context into a Collection in the DistributedObjectStore. 

Even though the world is moving towards IMDB(in-mempory data grid) solutions maintained in a separate box, I have seen from my experience that we tend to develop a heap memory solution along with IMDB to achieve the best performance, especially in the world of Microservices. The IBM dynacache comes really handy in these scenarios. A much better solution than ConcurrentHashMap. 

In my next article. I will show how I have auto-configured eXtreme Scale in the application. It is a licensed product from IBM, which is an elastic, scalable, in-memory data grid caching solution.