2

我不清楚以下之间是否应该存在 1-1 或 1-* 关系：

  1. 服务器连接通道和 JMS 主题
  2. 服务器连接通道和监听器
  3. 听众和主题

关于我们应用层的设计，有一个 MDB 响应消息，做一些工作，然后将消息发布到各种输出主题上。服务层正在监听这些输出主题。

目前我在 Channel-Listener-Topic 之间有一个 1-1-1，因此每个发布者（在应用程序端）和侦听器（在服务端）都有一个 JmsConnectionFactory 实例。

4

2 回答 2

1

有几种不同的方式来看待这个问题。从您的应用程序的角度来看，一个连接工厂可以有许多会话。每个会话可能有许多消费者，但工作单元的范围是每个会话，而不是每个消费者。因此，您很可能想要一个具有多个会话的连接工厂，其中每个会话都有一个特定主题的侦听器。如果您在单个会话中为多个使用者分配了一个侦听器，则任何确认（或事务会话中的 COMMIT）都会提交该会话中获取或放入的所有消息。

从 WMQ 服务器的角度来看，一个通道定义可以有多个运行实例。因此，您只需要为每个应用定义一个 SVRCONN 通道，而不管它需要启动多少个通道实例。尽量不要将不同的应用程序放在同一个 SVRCONN 上，因为您经常希望单独管理或授权应用程序。例如，使用不同频道上的应用程序，如果您突然发现自己有 3000 个正在运行的频道，您可以轻松找出哪个应用程序行为不端。

出于管理和调试的目的，我可能有一个 CF 用于应用程序端，一个 CF 用于服务端。如上所述，每个都将指向不同的 SVRCONN 通道。在应用服务器内部，我会坚持每个会话使用一个主题，除非您的应用在单个工作单元中消耗多个主题是有效的。在订阅中，您可以指定通配符主题以使用单个订阅者获取主题树中某个点以下的所有主题。

仅出于最佳实践，我还将 CF 设置为使用 FAILIFQUIESCE 以确保 QMgr 可以有序地停止，并且我将使用 SYNCPOINTALLGETS （或具有显式提交调用的事务会话）以提高可靠性JMS 1.1 规范第 4.4.13 节规定：

如果在客户端在 Session 上提交其工作和 commit 方法返回之间发生故障，则客户端无法确定事务是提交还是回滚。当在 PERSISTENT 消息的非事务性发送和发送方法的返回之间发生故障时，存在同样的歧义。由 JMS 应用程序来处理这种歧义。在某些情况下，这可能会导致客户端生成功能上重复的消息。

由于会话恢复而重新传递的消息不被视为重复消息。

SYNCPOINTALLGETS（又名 SPAG）确保从队列中检索到的消息在提交并从队列中永久删除之前传递到您的应用程序。否则，如果您在 QMgr 尝试返回消息时失去连接，它就永远消失了。使用 SPAG 集，您可能会看到两次 JMS 规范中描述的相同消息，但您永远不会丢弃一个。

有关 CF、队列和主题对象可用选项的更多详细信息，请参阅：WebSphere MQ 使用 Java 手册中的对象属性。

WMQ v6.0 已于 2012 年 9 月终止，因此请务必使用 v7 客户端进行开发，即使服务器是 v6。这将减少您明年的迁移工作。在此处下载 v7 客户端和在此处下载WMQ v7.1 客户端。

于 2010-07-08T03:54:42.243 回答
1

容器中的 MDB 创建并发处理消息的 MDB 池。如果您只是处理并写入该主题，那么您会很好。考虑到这一点，您没有 1-1-1 的关系。

在您的 MDB 中，只需对您的 TopicConnectionFactory 和您的主题进行 JNDI 查找，然后编写即可。看这里： http: //middleware.its.state.nc.us/middleware/Documentation/en_US/htm/csqzaw09/csqzaw0931.htm

于 2010-07-07T18:44:36.247 回答