Beans gérés par messages - Prise en charge des transactions
Dans le cadre d'une transaction, les beans gérés par messages peuvent traiter les messages sur les destinations (ou points de contact) dans la portée d'une transaction.
Traitement des transactions lors de l'utilisation du service d'écoute de messages avec IBM MQ JMS
Il existe trois cas de figure, suivant les réglages choisis dans le descripteur de déploiement du bean de message : transaction gérée par le conteneur (obligatoire), transaction gérée par le conteneur (non prise en charge) et transaction gérée par le bean.
Dans le descripteur de déploiement d'un bean de message, vous pouvez choisir si le bean gère lui-même ses propres transactions ou si le conteneur gère les transactions pour le compte du bean. Si vous optez pour la gestion des transactions par le conteneur, dans le bloc-notes du descripteur de déploiement, vous pouvez sélectionner, pour chaque méthode du bean, un type de transaction indiquant si la gestion par le conteneur est obligatoire ou non prise en charge. La valeur par défaut est Transaction gérée par conteneur (obligatoire).
- Transaction gérée par conteneur (obligatoire)
Dans ce cas, le serveur d'applications démarre une transaction globale avant de lire les messages entrants depuis la destination et avant qu'il n'appelle la méthode onMessage() du bean de message. Cela signifie que d'autres EJB appelés à leur tour par le message et que les interactions avec les ressources telles que les bases de données peuvent être sectorisés dans cette même transaction globale ayant obtenu le message entrant.
Si ce flux d'application réussit, la transaction globale est validée. Dans le cas contraire (si la transaction est marquée pour annulation ou si une erreur d'exécution se produit), la transaction est annulée et le message entrant est à son tour annulé sur la destination du bean de message.
- Transaction gérée par conteneur (non prise en charge)
Dans ce cas, il n'y a pas de transaction globale, mais le fournisseur JMS peut toujours livrer un message d'une destination de bean de message au serveur d'applications dans une unité de travail. Cette dernière peut être considérée comme une transaction locale, car aucune autre ressource n'est impliquée dans sa portée transactionnelle.
Le serveur d'applications accuse réception du message lorsque la distribution de l'appel onMessage() réussit sur le bean de message (à l'aide du mode de reconnaissance indiqué par l'assembleur du bean de message).
Le serveur d'applications n'accuse toutefois pas réception si une exception d'exécution non contrôlée est lancée depuis la méthode onMessage(). Le message est-il donc annulé sur la destination du bean de message (ou a-t-il été acquitté et supprimé ) ?
La réponse varie selon qu'un point de synchronisation est utilisé ou non par le fournisseur JMS et suivant la plateforme d'exploitation utilisée (le comportement de la plateforme d'exploitation z/OS peut en particulier entraîner un autre comportement).
Si votre fournisseur JMS MQ établit un point de synchronisation autour de la consommation du message par le bean de message dans ce cas de transaction gérée par conteneur (non prise en charge), le message est annulé sur la destination après une exception non contrôlée.
Si aucun point de synchronisation n'est utilisé, le message est supprimé de la destination après une exception non contrôlée.
Pour plus d'informations à ce sujet, voir la note technique "MDB behavior is different on z/OS than on distributed when getting nonpersistent messages within syncpoint" sur http://www.ibm.com/support/docview.wss?uid=swg21231549.
- Transaction gérée par bean
Dans cette situation, l'action est identique à celle de la transaction gérée par conteneur (non prise en charge). Bien qu'une transaction utilisateur puisse intervenir dans ce cas, si elle a lieu pendant la distribution de l'appel onMessage du bean de message, elle n'inclut pas la consommation du message depuis la destination du bean dans la portée de la transaction. Pour cela, utilisez le scénario transaction gérée par conteneur (obligatoire).
Redistribution des messages
Dans les trois cas précédents, un message annulé sur la destination du bean de message est, à terme, redistribué. Si l'annulation d'origine était due à un problème système temporaire, il est probable qu'une nouvelle distribution du bean de message avec ce message réussira. Si, toutefois, l'annulation est liée à un problème spécifique lié au message, le message peut être annulé et redistribué à plusieurs reprises. Cette situation est appelée Scénario de message incohérent.
Si votre système de messagerie utilise des ports d'écoute, le serveur d'applications gère ce scénario, en effectuant le suivi de la fréquence à laquelle un message est distribué et en arrêtant le port d'écoute associé après un nombre défini de redistributions.
- Nombre maximal de tentatives
- Le paramètre Nombre maximal de tentatives définit le nombre de fois où le programme d'écoute tente de transmettre un message spécifique à l'instance de bean gérée par message avant l'arrêt du programme d'écoute.
- Si la valeur 0 est attribuée à ce paramètre, le port d'écoute s'arrête après un seul échec de distribution de message.
Si votre système de messagerie utilise des spécifications d'activation, le scénario de message incohérent est géré de manière légèrement différente. Alors que les ports d'écoute effectuent le suivi du nombre d'échecs d'un message spécifique suivis de sa redistribution, les spécifications d'activation comptent le nombre d'échecs séquentiels de distribution de message.
- Arrêt automatique des noeuds finaux sur l'échec répété des messages
- Vous devez vous assurer que cette option est sélectionnée.
- Cette propriété interrompt la distribution des messages au noeud final lorsque le Seuil des messages d'échec séquentiel est atteint.
- Seuil d'échecs de messages séquentiels
- Ce paramètre détermine le nombre d'échecs de distribution de message avant l'interruption de cette action.
- Pour pouvoir activer ce paramètre, l'option Arrêter automatiquement les noeuds finaux lors d'échecs répétés des messages doit être sélectionnée.
- Fréquence entre deux échecs de message
- Ce paramètre définit la durée qui s'écoule entre deux tentatives de distribution de message.
- Si vous avez indiqué la valeur 0 pour ce paramètre, la tentative de nouvelle distribution a lieu immédiatement.
- Pour pouvoir activer ce paramètre, l'option Arrêter automatiquement les noeuds finaux lors d'échecs répétés des messages doit être sélectionnée.
- Arrêt du noeud final en cas d'échec de distribution des messages
- Vous devez vous assurer que cette option est sélectionnée.
- Cette propriété interrompt la distribution des messages au noeud final lorsque le Nombre d'échec de distribution séquentiels avant la mise en suspens du noeud final est atteint.
- Nombre d'échecs de distribution séquentielle avant la suspension du noeud final
- Ce paramètre détermine le nombre d'échecs de distribution de message avant l'interruption de cette action.
- Pour activer ce paramètre, l'option Arrêter le noeud final en cas d'échec de distribution des messages doit être sélectionnée.
Au lieu d'avoir recours au serveur d'applications pour arrêter le port d'écoute ou la spécification d'activation lorsqu'il existe des messages incohérents, vous pouvez configurer IBM MQ afin qu'il résolve le problème. Pour les destinations de file d'attente, spécifiez une file d'attente d'annulation (BOQUEUE) et une valeur de seuil d'annulation (BOTHRESH) dans l'objet file d'attente dans IBM MQ. Pour les destinations de sujet, spécifiez une file d'attente d'annulation (BOQUEUE) et une valeur de seuil d'annulation (BOTHRESH) pour les files d'attente système IBM MQ SYSTEM.DURABLE.MODEL.QUEUE et SYSTEM.NDURABLE.MODEL.QUEUE. IBM MQ gère alors le message incohérent. Pour plus d'informations sur la gestion des messages incohérents, voir la section IBM MQ Using Java™ de la bibliothèque IBM MQ.