regroupement / réplication d'un état de compteur avec une étendue de niveau d'application

Question

Je dois répliquer une séquence / un compteur sur un cluster à huit nœuds. Cela signifie que chaque demande http reçoit la valeur suivante de la séquence en appelant quelque chose comme getNextIntAndIncrement (), où l'état de la séquence est synchronisé sur tous les serveurs. Pour clarifier, cela doit exister au niveau application / global, pas en session. Je sais que cela semble une idée terrible et mènera sans aucun doute à un goulot d'étranglement, mais c'est l'exigence.

Ma question est quelle est la meilleure solution? J'ai examiné les beans de session avec état, mais ils semblent être conçus pour un seul client. J'ai considéré une séquence de base de données. J'ai aussi examiné le regroupement de Terracotta; ils ont une démo de séquence http://www.terracotta.org/web / display / orgsite / Recipe? recipe = sequencer Toutefois, j'aimerais éviter les solutions tierces si une solution J2EE existe. J'utilise Weblogic 8.1.

Answer 1

Certains fournisseurs Java EE ont des solutions de cache distribuées (par exemple, Object Grid de WebSphere) et vous avez déjà identifié des offres tierces mais je ne crois pas qu'il existe une norme portable.

Quel est le problème avec la solution DB? Il est clair que le verrouillage va être nécessaire, alors pourquoi ne pas laisser à la DB. Mon hypothèse est que si vous avez vraiment besoin de vraies valeurs incrémentielles, qu'aucune valeur ne soit omise, etc., les relations transactionnelles avec d'autres valeurs de base de données seront donc importantes. Utilisez donc la base de données.

Si vous pouvez assouplir le besoin de valeurs séquentielles absolues (c.-à-d. autoriser les espaces vides), vous pouvez fragmenter des ensembles de nombres et ainsi réduire considérablement les conflits. Si vous avez vraiment besoin de valeurs séquentielles, sans espace, vous reconnaissez le besoin d'un certain degré de verrouillage entre les instances - vous ne pouvez pas autoriser un deuxième "thread". pour obtenir un nouveau numéro de séquence jusqu'à ce que vous "validiez" l'utilisation de l'actuel. Si vous pouvez vous permettre de perdre le numéro de séquence impair, vous faites beaucoup mieux. Ou, si vous pouvez utiliser des schémas de numérotation indépendants entre les instances, vous occuperez une bien meilleure position. Par exemple, nommez vos serveurs a, b, c ... ont les identifiants a001, a002, b001, c001, c002, etc.

Answer 2

Je pense qu'une séquence de base de données vous donnerait probablement le résultat le plus déterministe, en particulier si vous utilisez des transactions hautement sérialisées pour le demander.

Cependant, je mets sérieusement en doute la validité de faire quelque chose comme cela, mais ce n’est que mes 2 centimes.

Answer 3

Vous avez weblogic dans les balises de cette question - Weblogic autorise les singletons de cluster. par exemple. une instance par cluster avec prise en charge du basculement.

Cela devrait répondre à vos besoins:

http: // e-docs .bea.com / wls / docs100 / javadocs / weblogic / cluster / singleton / SingletonService.html