Повторное использование объекта IBM.WMQ.MQQueue

Question

Мы используем .NET API для IBM WebSphere MQ.

Создание объекта MQQueueManager явно дорогостоящей операции, поэтому мы кэшем и повторно используем пул этих объектов.

В настоящее время, для каждого запроса, мы получаем доступ необходимые очереди:

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

и закрыть их когда-то сделали:

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

Является ли это лучшая практика, или мы должны быть также объединение и повторное использование Объекты MQQueue (в дополнение к диспетчеру очереди)? AccessQueue() кажется дешевой операцией на клиенте.

Answer 1

Ответ зависит от вашей модели резьбы и транзакционной ситуации. В общем, клиенты обмена сообщениями всегда должны использовать транзакцию, даже если это только однофазное совершение. Причина в том, что существуют неоднозначности результатов, которые могут вызвать дублирование или потерянные сообщения в противном случае. Я привел более подробное объяснение этого in another answer.

Проблема заключается в том, что операции связаны с областью. Когда вы COMMIT, вы делаете это для всего соединения. Использование одного и того же соединения по нескольким потокам безопасно предотвратит использование транзакций и, таким образом, выведет приложение на потерянные или дублированные сообщения. Поскольку дескрипторы очереди действительны только в контексте конкретного соединения, они наследуются от вашей модели потоков и пула соединений.

Наиболее распространенной моделью для приложения-поставщика услуг является поддержание соединения в потоке во входной очереди и динамическое открытие/размещение/закрытие выходной очереди. Например, в одной единице работы ...

1. Прочитайте следующий запрос сообщение
2. Используйте для ответа информации для получения конечного пункта;
3. Откройте для ответа очереди
4. Поместит ответ
5. Commit
6. уничтожить ответ-к месту назначения объекта и таким образом закрыть ответ-очереди

В этом случае соединения не постоянно перестраиваются, и очередь ввода не закрывается. Тем не менее, для каждого потока требуется поддерживать выделенное соединение.