![[z/OS]](../images/ngzos.gif)
Paramètres de fabrique de connexions des beans gérés par message ASF qui utilisent WebSphere MQ comme fournisseur de messagerie sur z/OS
Vous pouvez optimiser les paramètres de fabrique de connexions pour contrôler la création des connexions et de sessions du travail d'un bean géré par message.
Paramètres de la fabrique de connexions
Pour attacher une application et un serveur à un gestionnaire de files d'attente avec des paramètres d'authentification, les applications et les ports d'écoute des messages sont liés à des fabriques de connexions. Le serveur utilise le même modèle d'administration pour écouter les messages qui arrivent pour être remis aux beans gérés par messages que l'application pour exploiter JMS, dans la mesure où les ports d'écoute des messages sont liés à une fabrique de connexions de file d'attente (ou fabrique de connexions de sujet) et une file d'attente correspondante (ou sujet).
Pour chaque fabrique de connexions, vous devez définir des paramètres de fournisseur de messagerie (par exemple, les paramètres du gestionnaire de files d'attente), des paramètres de pool de connexions et des propriétés de pool de session. Les paramètres de la propriété de nombre maximal de connexions de pool de connexions et de la propriété de nombre maximal de pools de session d'une fabrique de connexions varient selon que vous utilisez la fabrique de connexions pour un port d'écoute, une application ou les deux.
Paramètres de nombre maximal de connexions de pool de connexions
- Le nombre de beans gérés par messages mappés à un port d'écoute mappé dans la fabrique de connexions
- Un bean géré par message peut obtenir une connexion JMS en exécutant sa logique d'application dans onMessage(), par exemple :
- Le transfert du message vers une autre destination pu envoi d'une réponse
- Le mise à jour d'un journal, mais exécution d'aucun appel JMS associé seul
Dans tous les cas, comptez '1' pour ce bean géré par message, car il s'agit de la connexion utilisée par le port d'écoute.
Si la logique onMessage() du bean géré par message obtient une connexion JMS, ajoutez le nombre d'unités d'exécution de tâche de serviteur au nombre maximal de connexions. Sinon, ajoutez le nombre maximal de connexions pour ce composant d'application de bean géré par message.
- Le nombre maximal de connexions
- Tout d'abord, recherchez le nombre maximal de connexions obtenues dans une seule répartition d'application (généralement ‘1') en vérifiant toutes les applications qui utilisent cette fabrique de connexions. Multipliez ensuite cette valeur par le nombre d'unités d'exécution de tâche dans un serviteur pour calculer le nombre maximal de connexions. Remarque :
- Comptez uniquement les unités d'exécution de tâche d'un seul serviteur, car chaque serviteur a sa propre fabrique de connexions avec des pools de connexions et de sessions.
- Incluez également d'autres composants d'application non-MDB qui utilisent cette fabrique de connexions pour exécuter des appels JMS. Toutefois, quel que soit le nombre de beans géré par message (MDB) ou de composants d'application non-MDB qui utilisent cette fabrique de connexions le nombre maximal de connexions correspond au nombre d'unités d'exécution de tâche de serviteur (et non pas au nombre d'applications multiplié par le nom d'unités d'exécution de tâche de serviteur s'ils utilisent chacun une seule connexion JMS pour chaque répartition).
Paramètres du Maximum de connexions du pool de sessions
Pour le traitement du port d'écoute JMS dans tous les cas généraux, affectez à la propriété du nombre maximal de connexion de pool de sessions le nombre d'unités d'exécution de tâche dans un seul serviteur.
Cela s'explique par le fait que les sessions JMS ne sont pas partagées sur les répartitions d'applications ou par l'infrastructure de port d'écoute, même pour les clients de la même fabrique de connexions. Le fait qu'un seul pool de sessions soit obtenu pour chaque connexion JMS auprès de la fabrique de connexions est également une explication (bien que les paramètres de la propriété du pool ne soient définis qu'une seule fois, au niveau de la fabrique de connexions).
On peut imaginer une situation dans laquelle la même fabrique de connexions serait utilisée par un port d'écoute et par une application, cette dernière ayant une plus grande exigence en termes de Maximum de connexions dans le paramètre du pool de sessions, mais ce sujet ne mérite pas de retenir notre attention.
Est-il conseillé d'utiliser peu ou beaucoup de fabriques de connexions ?
Vous pouvez décider de simplifier ces calculs, par exemple, en créant une fabrique de connexions distincte pour chaque bean MDB (dans ce cas le nombre maximal de connexions de pool de connexions est égal à 1). Peut-être souhaiterez-vous plutôt gérer moins d'objets d'administration de fabrique de connexions.
Les connexions et les sessions utilisées pour le traitement MDB ne peuvent pas être partagées (à savoir qu'elles ne peuvent pas être utilisées par plusieurs flux simultanément). Ceci implique qu'il ne faut pas considérer le regroupement comme un moyen d'utiliser moins de fabriques de connexions. En d'autres termes, l'ajout d'une autre fabrique de connexions n'empêche en aucun cas le regroupement de connexions qui pourrait être exploité par le traitement du port d'écoute du bean géré par message.
Exemples de fabriques de connexions
- Chaque servant possède 12 tâches. (Le nombre de servants dans le serveur importe peu étant donné que chaque servant reçoit ses propres pools).
- Le port d'écoute LP1 est mappé sur la fabrique de connexions CF1. Le bean de gestion des messages MDB1 est mappé LP1. Le code d'application onMessage() de MDB1 met un nouveau message dans la file d'attente de transfert. MDB1 a donc une référence de ressource qui est également résolue sur CF1.
- De même, dans le même serveur, le port d'écoute LP2 est défini et mappé sur la fabrique de connexions CF2. Les beans gérés par message MDB2A et MDB2B sont définis dans le même fichier ejb-jar et sont tous les deux mappés sur LP2 avec des sélecteurs JMS complémentaires. Le code d'application onMessage() de MDB2A et MDB2B procèdent tous les deux à une journalisation, mais aucun bean géré par message n'appelle une API JMS de son propre chef.
- Pour la fabrique de connexions CF1, nous comptons 1 pour MDB1. L'application MDB1 (qui utilise également une fabrique de connexions CF1 pour envoyer son message de transfert) utilise une connexion JMS pour laquelle vous comptez le nombre de tâches (12), multiplié par un. Notre total du Maximum de connexions du pool de connexions pour la fabrique de connexions CF1, est alors de 13 = 12 + 1.
- Pour la fabrique de connexions CF2, comptez un pour MDB2A et un pour MDB2B. Aucune application utilise CF2 (uniquement l'infrastructure de port d'écoute) ; par conséquent, affectez la valeur 2 à la propriété de nombre maximal de connexions de pool de connexions de la fabrique de connexions CF2.
- Pour chacune des deux fabriques de connexions, le Maximum de connexions du pool de sessions est défini à 12.
- A nouveau, chaque servant possède 12 tâches. Dans cet exemple, vous ne voulez utiliser qu'une seule fabrique de connexions, CF1.
- Chacun des deux ports d'écoute LP1 et LP2 est mappé à la fabrique de connexions CF1. Les beans gérés par message MDB1, MDB2 et MDB3 font partie de trois fichiers EAR d'application uniques. MDB1 est mappé sur LP1, mais MDB2 et MDB3 sont tous deux mappés à LP2.
- Jusqu'ici, vous estimiez avoir besoin de trois connexions pour la fabrique de connexions CF1. Il existe cependant un composant de servlet qui place des messages dans une file d'attente et qui utilise la même fabrique de connexions CF1. Donc, pour la fabrique de connexions CF1, le Maximum de connexions du pool de connexions est égal à 15 = 3 + 12.