DistributedMap comme cache groupé avec Terracotta

Question

Lorsque vous choisissez l'implémentation de cache appropriée pour être mis en cluster avec Terracotta, j'ai utilisé le module d'intégration de Terracotta séparé DistributedMap qui fournit des capacités de cache de base telles que la prise en charge de différentes politiques d'expulsion. facile à configurer, mais en ce qui concerne la mise en grappe prête pour la production, j'ai trouvé que je devais trouver des réponses à quelques questions: 1. Est-ce que anyboby a déjà utilisé ce TIM, y a-t-il quelqu'un qui a essayé TIM? Des erreurs? 2. DistributedMap est facile à configurer, mais qu'en est-il du scénario suivant: que se passe-t-il si nous démarrons 2 clients Terracotta et que chacun de ses DistributedMap sera configuré différemment? Le serveur Terracotta mettra-t-il à jour la configuration existante, fournie par client1 ou laissera-t-elle simplement inchangée.

Answer 1

Je viens de parler à un client aujourd'hui en utilisant DistributedMap en production. En ce qui concerne la configuration - je crois que la configuration est contenue dans l'instance. Puisqu'un DistributedMap ne contient aucune racine où l'état partagé chevaucherait une autre instance, chaque instance serait séparée l'une de l'autre (ce qui signifie que vous pouvez créer autant de DistributedMaps indépendants que vous le souhaitez).

Notez qu'un DistributedMap n'est pas réellement mis en cluster tant que vous ne l'avez pas mis en cluster en l'ajoutant à un graphique partagé. Cela peut être fait en l'ajoutant à un POJO déjà en cluster (de votre propre création, ou par exemple une HashMap déjà en cluster) ou en le marquant comme root (une approche commune et celle suggérée par le docs).