Cluster Communication
A Jmix application can be deployed in a cluster of multiple interconnected servers to distribute workloads, enhance reliability, and optimize resource utilization. The Kubernetes Cluster section provides a practical guide on cluster deployment.
This section contains information about what Jmix mechanisms participate in the cluster communication and what underlying technologies are used. It can be helpful for troubleshooting and for implementing your own ways of cluster communication.
Jmix subsystems require two distinct ways of communication: shared cache and messaging. Both are used through high-level abstractions that can have different implementations. The default implementation is Hazelcast.
Shared Cache
The shared cache is used by the following Jmix features:
-
Query Cache - to store results of query execution.
-
Security - to store resource and row-level roles configuration.
-
Pessimistic Locking - to maintain distributed locks.
-
Dynamic Attributes - to store dynamic attributes configuration.
All these mechanisms rely on Spring Cache and JCache APIs. As an example, the following diagram shows classes involved in Jmix query caching:
The StandardQueryCache class uses Spring Cache for most operations. It also uses JCache through the CacheOperations utility class to iterate through the cache entries, because Spring Cache doesn’t provide such a function.
The other Jmix features listed above use the shared cache in the same way.
The application project should provide a JCache implementation for Spring Cache. For example, to use Hazelcast, add the dependency:
implementation 'com.hazelcast:hazelcast'and define the property:
spring.cache.jcache.provider = com.hazelcast.cache.HazelcastMemberCachingProviderMessaging
The messaging is used by the following Jmix features:
-
Entity Cache - to broadcast changes in cached entities.
-
Notifications - to broadcast in-app notifications.
These features rely on Spring Messaging abstraction: SubscribableChannel interface. Jmix provides implementations of this interface delegating to the Hazelcast’s ITopic:
These implementations are automatically instantiated in your project if you add a dependency to Hazelcast.
If you want to use another messaging provider, create your own Spring beans implementing the EclipseLinkChannelSupplier interface for entity cache and InAppSubscribableChannelSupplier interface for notifications.
