Current Carbon-Kernel v4.4.0 caching is based on JCache v0.5. This Blog is about new JSR107 (JCache) v1.0 update in Carbon-Kernel based on new Hazelcast caching provider.
Topics
- What is JCache
- Whats in latest JSR107 (JCache) in high level view
- WSO2 Caching
- New caching API changes in WSO2 Caching
- Examples of new caching API
Caching is proven method to increase scalability and performance. JCache (JSR 107) is a standard caching API for Java. It can keeps some data in low-latency data structures for some period.It provides an API to create and work with in-memory cache of objects. It allows to create, access, update and remove entries from caches.JCache API only provides set of high level components (interfaces) to work with caching other than thinking about the implementation of the caching
Some common use cases
- Client side caching of Web service calls
- Caching of expensive computations such as rendered images
- Caching of data
- Servlet response caching
- Caching of domain object graphs
Latest JSR107 (JCache) in high level view
Caching Provider – used to control Caching Managers and can deal with several of them,
Cache Manager – deals with create, read, destroy operations on a Cache
Cache – stores entries (the actual data) and exposes CRUD interfaces to deal with the entries
Entry – abstraction on top of a key-value pair akin to a java.util.Map
WSO2 Caching
Core Features
Cache Manager – deals with create, read, destroy operations on a Cache
Cache – stores entries (the actual data) and exposes CRUD interfaces to deal with the entries
Entry – abstraction on top of a key-value pair akin to a java.util.Map
WSO2 Caching
- Local and distributed mode
- L1 and L2 caching model for distributed mode
- Multi-tenancy
L1 and L2 caching model for distributed mode: In order to improve performance there are 2 types of caching models called L1(Level 1) and L2(Level 2) caching, L1 cache is implemented by HashMaps, and new L2 cache is implemented by Hazelcast cache (wrapper of jcache v1.0 API).Every first time it checks in L1 cache but if the value is located in the L2 cache, then the value is also stored in the L1 cache
Multi-tenancy: It can cache and provide tenant specific data and make it available in every and each cluster members.
Sequence diagram of L1 and L2 caching model
In the distributed mode, if a cache entry is removed, invalidated or changed then the Hazelcast Cache Entry listeners that registered will trigger on each and every Hazelcast cluster member, In that same time L1 cache and the L2 cache being removed or updated
Sequence diagram of remove item
- In previous jcache version, to create a CacheManager object had to call CacheManagerFactory and parse the name to CacheManager
- Caching.getCacheManagerFactory().getCacheManager("sampleCacheManager");
- New version of jcache use CachingProvider to create CacheManager by parsing a URI(String) object
- Caching.getCachingProvider().getCacheManager(new URI("sampleCacheManager"));
- To create a custom cache with custom configuration no need to call createCacheBuilder() to and parse the configuraion object, now CacheManager can directly call getCache() by parsing a cacheName and CacheConfiguration object
- Other than that the org.wso2.carbon.caching.impl.CacheImpl class distributedCache is changed to Hazelcast cache (v4.3) insted of using Hazelcast Maps
- hazelcastCacheManager = DataHolder.getInstance().getHazelcastCacheManager();
- Because the Hazelcast cache is distrbuted one, There's no need of having registered OSGI service called DistributedMapProvider so the service intarface has removed from the org.wso2.carbon.caching and also from the org.wso2.carbon.core.clustering.HazelcastDistributedMapProvider
- Other API changes are done to
- org.wso2.carbon.user.core
- org.wso2.carbon.registry.core
Example: Simple cache creation
Example: Using cache configuration with a custom cache expiry
Please feel free to test out the new jcache v1.0 implementation
References:
