이 콘텐츠는 선택한 언어로 제공되지 않습니다.

28.2. Key Affinity Service


The key affinity service allows a value to be placed in a certain node in a distributed Red Hat JBoss Data Grid cluster. The service returns a key that is hashed to a particular node based on a supplied cluster address identifying it.
The keys returned by the key affinity service cannot hold any meaning, such as a username. These are only random identifiers that are used throughout the application for this record. The provided key generators do not guarantee that the keys returned by this service are unique. For custom key format, you can pass your own implementation of KeyGenerator.
The following is an example of how to obtain and use a reference to this service.

Example 28.2. Key Affinity Service

EmbeddedCacheManager cacheManager = getCacheManager();
Cache cache = cacheManager.getCache();
KeyAffinityService keyAffinityService = 
        KeyAffinityServiceFactory.newLocalKeyAffinityService(
            cache,
            new RndKeyGenerator(),
            Executors.newSingleThreadExecutor(),
            100);
Object localKey = keyAffinityService.getKeyForAddress(cacheManager.getAddress());
cache.put(localKey, "yourValue");
Copy to Clipboard Toggle word wrap
The following procedure is an explanation of the provided example.

Procedure 28.1. Using the Key Affinity Service

  1. Obtain a reference to a cache manager and cache.
  2. This starts the service, then uses the supplied Executor to generate and queue keys.
  3. Obtain a key from the service which will be mapped to the local node (cacheManager.getAddress() returns the local address).
  4. The entry with a key obtained from the KeyAffinityService is always stored on the node with the provided address. In this case, it is the local node.

28.2.1. Lifecycle

KeyAffinityService extends Lifecycle, which allows the key affinity service to be stopped, started, and restarted.

Example 28.3. Key Affinity Service Lifecycle Parameter

public interface Lifecycle {  
     void start();   
     void stop();
}
Copy to Clipboard Toggle word wrap
The service is instantiated through the KeyAffinityServiceFactory. All factory methods have an Executor, that is used for asynchronous key generation, so that this does not occur in the caller's thread. The user controls the shutting down of this Executor.
The KeyAffinityService must be explicitly stopped when it is no longer required. This stops the background key generation, and releases other held resources. The KeyAffinityServce will only stop itself when the cache manager with which it is registered is shut down.

28.2.2. Topology Changes

KeyAffinityService key ownership may change when a topology change occurs. The key affinity service monitors topology changes and updates so that it doesn't return stale keys, or keys that would map to a different node than the one specified. However, this does not guarantee that a node affinity hasn't changed when a key is used. For example:
  1. Thread (T1) reads a key (K1) that maps to a node (A).
  2. A topology change occurs, resulting in K1 mapping to node B.
  3. T1 uses K1 to add something to the cache. At this point, K1 maps to B, a different node to the one requested at the time of read.
The above scenario is a not ideal, however it is a supported behavior for the application, as the keys that are already in use may be moved over during cluster change. The KeyAffinityService provides an access proximity optimization for stable clusters, which does not apply during the instability of topology changes.
맨 위로 이동
Red Hat logoGithubredditYoutubeTwitter

자세한 정보

평가판, 구매 및 판매

커뮤니티

Red Hat 문서 정보

Red Hat을 사용하는 고객은 신뢰할 수 있는 콘텐츠가 포함된 제품과 서비스를 통해 혁신하고 목표를 달성할 수 있습니다. 최신 업데이트를 확인하세요.

보다 포괄적 수용을 위한 오픈 소스 용어 교체

Red Hat은 코드, 문서, 웹 속성에서 문제가 있는 언어를 교체하기 위해 최선을 다하고 있습니다. 자세한 내용은 다음을 참조하세요.Red Hat 블로그.

Red Hat 소개

Red Hat은 기업이 핵심 데이터 센터에서 네트워크 에지에 이르기까지 플랫폼과 환경 전반에서 더 쉽게 작업할 수 있도록 강화된 솔루션을 제공합니다.

Theme

© 2025 Red Hat