消息驱动Bean和消息消费顺序
我有一个 MDB，它订阅了一个主题，该主题发送消息，其内容最终保存到数据库。
我知道 MDB 是池化的，因此容器能够并行处理多个传入消息。就我而言，这些消息的消费（然后持久化）顺序很重要。我不希望 MDB 实例池在消息在 JMS 主题中发布时使用并以不同的顺序保留消息。
这会是一个问题吗？如果是这样，是否有办法告诉容器在消费消息时遵循严格的传入顺序？
I have an MDB that gets subscribed to a topic which sends messages whose content is eventually persisted to a DB.
I know MDBs are pooled, and therefore the container is able to handle more than one incoming message in parallel. In my case, the order in which those messages are consumed (and then persisted) is important. I don't want an MDB instance pool to consume and then persist messages in a different order as they get published in the JMS topic.
Can this be an issue? If so, is there a way of telling the container to follow strict incoming order when consuming messages?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
从那里复制：
以确保接收顺序与客户端发送消息的顺序相匹配，您必须执行以下操作：
将 MDB 的 max-beans-in-free-pool 设置为 1。这可确保 MDB 是消息的唯一使用者。
如果您的 MDB 部署在集群上，请将它们部署到集群中的单个节点，[...]。
Copied from there:
To ensure that receipt order matches the order in which the client sent the message, you must do the following:
Set max-beans-in-free-pool to 1 for the MDB. This ensures that the MDB is the sole consumer of the message.
If your MDBs are deployed on a cluster, deploy them to a single node in the cluster, [...].
您应该能够将 MDB 池的大小限制为 1，从而确保按照正确的顺序处理消息。
当然，如果您仍然想要一些并行性，那么您有几个选择，但这实际上取决于数据。
如果某些消息有一些共同点，并且处理顺序仅在共享共同值的消息组中起作用，那么您可能需要有多个主题，或者使用队列和线程池。
另一方面，如果与消息到达相关的逻辑的某些部分可以并行发生，而其他部分则不能，那么您需要将逻辑分为并行确定和并行不正常部分，并相应地处理这些位。
You should be able to limit the size of the MDB pool to 1, thus ensuring that the messages are processed in the correct order.
Of course, if you still want some parallelism in there, then you have a couple of options, but that really depends on the data.
If certain messages have something in common and the order of processing only matters within that group of messages that share a common value, then you may need to have multiple topics, or use Queues and a threadpool.
If on the other hand certain parts of the logic associated with the arrival of a message can take place in parallel, while other bits cannot, then you will need to split the logic up into the parallel-ok and parallel-not-ok parts, and process those bits accordingly.