我在努力理解如何验证IBM MQ中的物理连接与逻辑连接。我的理解是：

• 物理连接 → 指向队列管理器的TCP连接
• 逻辑连接（会话） → JMS会话（或MQ对话）

场景1（JMS）

• 创建了 1个 JMS连接
• 从该连接创建了 5个会话

场景2（MQ基本API）

• 创建了 5个 MQQueueManager 实例（独立连接）

使用的命令

检查连接：

DISPLAY QMSTATUS CONNS

检查对话（等同于会话）：

DISPLAY CHSTATUS(SYSTEM.DEF.SVRCONN) CURSHCNV

问题

在这两种场景中，我看到CONNS与 CURSHCNV的数值相同，例如：

CONNS(5)
CURSHCNV(5)

预期行为

对于JMS场景，我的预期是：

CONNS(1)
CURSHCNV(5)

因为只有一个物理连接且有多个会话。

额外背景

• 使用JMS API来创建会话
• 也使用MQ基本API进行测试（MQQueueManager）
• MQ Web控制台（UI）功能有限，无法清晰显示连接与会话的细节

问题

1. 为什么即使从单个JMS连接创建了多个会话，CONNS与 CURSHCNV显示相同的值？
2. JMS客户端实际上是在创建多条物理连接吗，还是在对会话进行复用？

3. 验证的正确方法是什么：

4. 物理TCP连接 的数量

5. IBM MQ中 逻辑会话（对话） 的数量？

通道配置（例如SHARECNV-10）

解决方案

一个JMS连接会产生一个MQCONN。

一个JMS会话会产生一个MQCONN。

多个MQCONN可以在一个物理TCP/IP套接字上共享。

使用CONNS或 CURSHCNV来统计MQCONN的数量。

使用CHSTATUS来统计物理TCP/IP套接字的数量。

共享与JMS连接上的JMS会话无关，共享由通道上的MAXSHCNV设置控制。如果把该值降到2，你会看到多个CHSTATUS，每个状态显示2 个共享会话通过各自的连接进行传输。