JBoss Cache’s goal is to provide enterprise-grade clustering solutions to Java-based frameworks, application servers or custom-designed Java SE applications.
Clustering for high availability
Since JBoss Cache is a replicated cache, state is always kept in sync with other servers in the cluster. This makes any state stored in JBoss Cache resilient to server crashes or restarts, achieving high availability.
Clustered caching to remove bottlenecks
JBoss Cache still is, as it’s name suggests, a cache. It is a product designed to cache frequently accessed Java objects in order to dramatically improve the performance of applications. This makes it easy to remove data access bottlenecks - such as connecting to a database.
And unlike non-cluster-aware caches which may go out of sync when there are concurrent updates, each JBoss Cache instance is aware of remote cache updates and can either invalidate or update it’s state.
Cluster high availability
JBoss Cache will automatically replicate the cached data and synchronize the cached data between the servers in the cluster, which ensures that any server restart will not affect the availability of the cache.
Cluster cache avoids system bottlenecks
As the name implies, JBoss Cache uses cache to improve system scalability. When our WEB system encounters a large number of database reads and writes, the bottleneck of the system will appear on the database side. JBoss Cache can just solve the problem of frequent database reading and solve this bottleneck.
In addition, because JBoss Cache's cache is synchronized between each server in the cluster, it will not affect the entire system if one cache server encounters performance problems.
JBoss Cache provides two caching methods: core cache (TreeCache) and POJO cache (TreeCacheAOP)
Core cache: directly stores the data passed to it in a tree structure. The key/value pairs are stored on the nodes of the tree, and they are all serialized POJO caches for replication or persistence: a more complex mechanism is used - using bytecode weaving to introspect the user class , and add a listener to the domain of the user class. Once the domain value changes, the listener will immediately notify the cache. For example, storing a large, complex object in the POJO cache will cause the POJO cache to introspect the object's bytecode and end up storing only the object's original fields in the tree structure. Once the field value changes, the cache only copies the changed field value without copying the entire user class, which is efficient fine-grained replication.
TreeCache is divided into three categories by function: Local Cache, Replication Cache and Invalidation Cache. Distributed Cache (replication and invalidation Cache) is divided into two types, synchronous (REPL_ASYNC) and asynchronous (REPL_SYNC) , synchronous
Cache is to wait for changes to be applied to other instances before returning when a Cache instance is modified, while asynchronous Cache is to return immediately when a Cache instance is modified.
cache mode
LOCAL - Local, non-clustered cache. The local cache does not participate in the cluster and does not communicate with other caches in the cluster. Therefore, their contents are not serialized either. However, we recommend serializing them to allow some flexibility if you want to change the cache mode one day in the future.
REPL_SYNC - Synchronous replication. A replicated cache replicates all changes to other caches in the cluster. Synchronous replication means that when replicating changes, the call blocks until a replication confirmation is received.
REPL_ASYNC - Asynchronous replication. Similar to REPL_SYNC above, a replicated cache replicates all changes to other caches in the cluster. Because of the asynchrony, the caller does not block until a copy confirmation is received.
INVALIDATION_SYNC - If the cache is configured to invalidate rather than replicate, every time data in the cache is updated, other caches in the cluster will receive a notification message that their data is stale and should be evicted from memory. This will reduce the overhead of replication, while still being able to invalidate stale data in remote caches.
INVALIDATION_ASYNC - Same as above, but this failure mode broadcasts the failure message asynchronously.