The key affinity service solves the following problem: for a distributed Infinispan cluster one wants to make sure that a value is placed in a certain node. Based on a supplied cluster address identifying the node, the service returns a key that will be hashed to that particular node.
Following code snippet depicts how a reference to this service can be obtained and used.
KeyAffinityService extends Lifecycle, which allows stopping and (re)starting it:
The KeyAffinityService, once started, needs to be explicitly stopped. This stops the async key generation and releases other held resources.
The only situation in which KeyAffinityService stops by itself is when the cache manager with wich it was registered is shutdown.
When a topology change takes place the key ownership from the KeyAffinityService might change. The key affinity service keep tracks of these topology changes and updates and doesn't return stale keys, i.e. keys that would currently map to a different node than the one specified. However, this does not guarantee that at the time the key is used its node affinity hasn't changed, e.g.:
- thread T1 reads a key k1 that maps to node A
- a topology change happens which makes k1 map to node B
- T1 uses k1 to add something to the cache. At this point k1 maps to B, different node than the one requested at the time of read.
Whilst this is not ideal, it should be a supported behaviour for the application as all the already in-use keys might me moved over during cluster change. The KeyAffinityService provides an access proximity optimisation for stable clusters which doesn't apply during topology changes.