我们正在使用的.NET API IBM的WebSphere MQ。

We are using the .NET API to IBM's WebSphere MQ.

创建MQQueueManager对象显然是一个昂贵的操作，所以我们缓存和重新使用这些对象池。

Creating the MQQueueManager object is clearly an expensive operation, and so we cache and reuse a pool of these objects.

目前，对于每个请求，我们访问所需的队列：

Currently, for each request, we access the required queues:

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

和关闭它们一旦这样做：

and close them once done:

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

这是最好的做法，或者我们应该也集中和重复使用的MQQUEUE对象（除队列管理器）？ AccessQueue（）似乎是在客户端上的廉价的操作。

Is this best practice, or should we be also pooling and reusing the MQQueue objects (in addition to the queue manager)? AccessQueue() appears to be a cheap operation on the client.

推荐答案

问题的答案取决于你的线程模型和事务性。在一般情况下，消息客户端应该总是使用事务性，即使这仅仅是单阶段提交。其理由是，有成果，可以以其他方式导致重复或丢失信息的歧义。我提供了一个更详细的解释了这个in另一种答案。

The answer depends on your threading model and transactionality. In general, messaging clients should always use transactionality, even if that is only single-phase commit. The reason is that there are ambiguities of outcomes that can cause duplicate or lost messages otherwise. I've provided a much more detailed explanation of this in another answer.

问题是，交易连接范围。当你提交你的整个连接这么做。使用在多个线程在同一连接安全地将preclude事务的使用，因此应用程序暴露在丢失或重复的消息。由于队列手柄仅在一个特定连接的情况下有效，它们从你的线程模型和连接池继承。

The issue is that transactions are connection-scoped. When you COMMIT you do so for the entire connection. Using the same connection across several threads safely would preclude the use of transactions and thus expose the app to lost or duplicate messages. Since queue handles are only valid in the context of a particular connection, they inherit from your threading model and connection pool.

有关服务提供商的应用程序最常用的模式是保持在输入队列中每个线程的连接和动态打开/把/关闭输出队列。例如，在工作的一个单元...

The most common model for a service provider application is to maintain a connection per-thread on the input queue and dynamically open/put/close the output queue. For example, in a single unit of work...

在这种情况下，连接未不断重建，也不是以往关闭输入队列。然而，它确实需要每个线程保持的专用连接。

In this case the connections are not constantly rebuilt, nor is the input queue ever closed. However, it does require each thread to maintain a dedicated connection.