Réutilisation de l'objet IBM.WMQ.MQQueue

Question

Nous utilisons l'API .NET pour IBM WebSphere MQ.

La création de l'objet MQQueueManager étant clairement une opération coûteuse, nous mettons en cache et réutilisons un pool de ces objets.

Actuellement, pour chaque demande, nous avons accès aux files d'attente requises:

//obtain queueManager from pool 
IBM.WMQ.MQQueue requestQ= queueManager.AccessQueue(requestQName, mqOptions); 
IBM.WMQ.MQQueue responseQ= queueManager.AccessQueue(responseQName, mqOptions); 

et les fermer une fois fait:

requestQ.Close(); 
responseQ.Close(); 

Est-ce la meilleure pratique, ou devrions-nous être mise en commun aussi et la réutilisation de la Des objets MQQueue (en plus du gestionnaire de files d'attente)? AccessQueue() semble être une opération bon marché sur le client.

Answer 1

La réponse dépend de votre modèle de thread et de votre caractère transactionnel. En général, les clients de messagerie doivent toujours utiliser la transactionnalité, même s'il ne s'agit que d'une validation en une seule phase. La raison en est qu'il existe des ambiguïtés de résultats qui peuvent entraîner des messages dupliqués ou perdus autrement. J'ai fourni une explication beaucoup plus détaillée de ce in another answer.

Le problème est que les transactions ont une portée de connexion. Lorsque vous vous engagez, vous le faites pour toute la connexion. L'utilisation sécurisée de la même connexion sur plusieurs threads empêcherait l'utilisation de transactions et exposerait ainsi l'application à des messages perdus ou en double. Étant donné que les handles de file d'attente ne sont valides que dans le contexte d'une connexion particulière, ils héritent de votre modèle de thread et de votre pool de connexions. Le modèle le plus courant pour une application de fournisseur de services est de maintenir une connexion par thread dans la file d'attente d'entrée et d'ouvrir/fermer/fermer dynamiquement la file d'attente de sortie. Par exemple, en une seule unité de travail ...

1. Lire le message suivant demande
2. Utilisez la réponse à l'information pour obtenir la destination
3. Ouvrez la réponse à la file d'attente
4. Mettre le réponse
5. Commit
6. Détruire la réponse à l'objet de destination et donc fermer la réponse à la file d'attente

Dans ce cas, les connexions ne sont pas constamment reconstruites et la file d'entrée n'est jamais fermée. Cependant, chaque thread doit maintenir une connexion dédiée.