Répartition des transactions

Utilisez JMS (Java Message Service) pour les modifications de transaction répartie entre différents groupes de serveurs ou dans des environnements mixtes.

JMS est un protocole idéal pour les modifications réparties entre différents groupes de serveurs ou dans des environnements mixtes. Par exemple, certaines applications qui utilisent eXtreme Scale peuvent être déployées sur IBM® WebSphere Application Server Community Edition, Apache Geronimo ou Apache Tomcat alors que d'autres applications peuvent être exécutées sur WebSphere Application Server version 6.x. JMS se prête parfaitement aux modifications réparties entre des homologues eXtreme Scale dans ces environnements différents. Les messages du gestionnaire de haute disponibilité sont transférés très rapidement mais peuvent uniquement répartir les modifications vers les machines virtuelles Java rassemblées dans un groupe central unique. JMS est plus lent mais il autorise le partage d'un ObjectGrid par des ensembles de clients d'applications plus importants et plus variés. JMS est adapté au partage de données dans un ObjectGrid entre un client Swing lourd et une application déployée sur WebSphere Extended Deployment.

Deux fonctionnalités pré-intégrées, le mécanisme d'invalidation de client et la réplication entre homologues, sont des exemples de répartition de modifications transactionnelles JMS. Voir Activation du mécanisme d'invalidation de client et les Configuration de la réplication entre homologues avec JMS pour plus d'informations.

Implémentation de JMS

JMS est implémenté pour la répartition de modifications transactionnelles à l'aide d'un objet Java qui se comporte comme un ObjectGridEventListener. Cet objet peut propager l'état à l'aide de l'une des quatre méthodes suivantes :
  1. Invalidate : toute entrée expulsée, mise à jour ou supprimée est retirée de toutes les machines virtuelles Java homologues à la réception du message.
  2. Invalidate conditional : l'entrée est expulsée uniquement si la version locale est identique ou ultérieure à celle disponible sur le diffuseur de publications.
  3. Push : toute entrée expulsée, mise à jour, supprimée ou insérée est ajoutée ou écrasée sur toutes les machines virtuelles Java homologues à la réception du message JMS.
  4. Push conditional : l'entrée est uniquement mise à jour ou ajoutée côté récepteur si l'entrée locale est moins récente que la version en cours de publication.

Mode écoute pour les modifications de publication

Le plug-in implémente l'interface ObjectGridEventListener pour intercepter l'événement transactionEnd. Lorsque eXtreme Scale appelle cette méthode, le plug-in tente de convertir la liste LogSequence pour toutes les mappes concernées par la transaction en un message JMS et ensuite de la publier. Le plug-in peut être configuré de façon à publier les modifications pour toutes mappes ou un sous-ensemble de mappes. Les objets LogSequence sont traités pour les mappes pour lesquelles la publication est activée. La classe LogSequenceTransformer de l'ObjectGrid sérialise vers un flux une liste LogSequence filtrée pour chaque mappe. Après sérialisation de toutes les listes LogSequence vers le flux, un message ObjectMessage JMS est créé et publié dans une rubrique connue.

Mode écoute pour les messages JMS et application à l'ObjectGrid locale

Le même plug-in lance une unité d'exécution qui tourne en boucle, recevant tous les messages publiés dans la rubrique connue. A l'arrivée d'un message, il transmet le contenu de ce dernier à la classe LogSequenceTransformer au niveau de laquelle il est converti en un ensemble d'objets LogSequence. Une transaction no-write-through est ensuite démarrée. Chaque objet LogSequence est fourni à la méthode Session.processLogSequence qui met à jour les mappes locales pour refléter les modifications. La méthode processLogSequence comprend le mode de répartition. La transaction est validée et le cache local reflète désormais les modifications. Pour plus d'informations sur l'utilisation de JMS pour la répartition de modifications de transaction, voir les Répartition de modifications entre des machines virtuelles Java homologues.