Dans une plateforme JCMS montée en cluster JSync, il est fortement recommandé de centraliser les écritures dans JStore. C’est naturellement le cas si la plateforme est en actif/passif (p. ex. en fail-over) mais si elle est en actif/actif (p. ex. en répartition de charge) les écritures peuvent avoir lieu sur plusieurs réplicas. Si les écritures de JStore ne sont pas centralisées, les phases de synchronisation JSync avec fusion seront plus nombreuses. Cela entrainera un accroissement du temps traitements et augmentera les risques de conflits. Tout cela ne concerne pas les écritures qui ont lieu dans JcmsDB. Sur une plateforme JCMS le volume d’écriture dans JStore est généralement très faible (5%) par rapport au volume d’écritures dans JcmsDB (95%). Par ailleurs ces écritures sont généralement produites par une petite partie des utilisateurs de la plateforme. Pour centraliser les écritures de JStore, il suffit donc de centraliser sur le même réplica ces utilisateurs. Ce réplica doit être le leader car c’est sur celui-ci que sont aussi déclenchées les écritures planifiées (p. ex. les changements d’état du workflow) Le module de contribution centralisée prend en charge la centralisation des membres qui font des écritures dans JStore. Il détecte les membres qui vont probablement écrire dans le store et il les redirige vers le leader. Pour cela, il se base sur les droits de contribution et surtout les contributions passées des membres. Si un membre a récemment effectué une écriture dans JStore alors la probabilité qu’il réitère est plus élevée qu’un membre qui n’a jamais écrit ou dont la dernière écriture date de plus d’un mois. Comme il s’agit d’un système prédictif, il se peut donc qu’un membre effectue quand même une écriture dans JStore alors qu’il n’est pas sur le leader. Lorsque cela arrive, JSync effectue une phase de synchronisation avec fusion puis ensuite le membre est redirigé sur le leader. Ses prochaines écritures seront alors bien centralisées.
Français