JMS事务-开销-如有可能，如何避免呢？

Question

在我们的应用程序中，我们从JMS Topic接收消息。

• 首先，我想知道JMS是否遵循FIFO策略。 如果不是，应用程序如何确定最新消息？

我们消耗消息（持久的订户和JMS会话被处理，开销很大），因为消息保留在JMS服务器上，直到事务提交/结束。 我们指定交易的原因是

• 我们正在使用缓存（休眠）技术和使用它的事务。 因此，我们正在使用两个事务，一个是JMS tx，一个是缓存技术tx。 当我们使用该消息时，我们希望在消息提交并将确认发送到JMS之前不发生任何事情。 缓存tx将首先提交，然后立即JMS tx将再次提交并确认消息，否则，两个tx都将回滚并重播该消息。 当前，我们将消息重播3次，然后，如果仍然发生异常，则将消息发送到不可处理的队列。

• 在许多消息同时发送到JMS并需要由我们的系统同时处理之前，这种方法可以正常工作。

• 我想知道您遇到这种情况时做了什么。 因为，维护持久预订和事务处理会话是JMS服务器上的一大笔开销，并且会耗尽服务器的性能。

Answer 1

JMS规范中未指定主题的消息排序，因此对此的官方答案是特定于JMS实现。 话虽这么说，除非特别重写以执行其他操作，否则我认为消息将以FIFO顺序传递。

对于事务，建议您考虑实施两个阶段的提交XA事务，因此您不需要两个单独的事务。 如果您的缓存实现支持XA，则JMS和Cache（和DB）事务将是相同的。

通常，我发现对于这些类型的事务处理消息，如果必须使用事务处理消息，则降低性能的最佳方法是在一个事务中处理尽可能多的消息：

1. 开始交易
2. 检索n条消息（或所有消息，直到出现超时）
3. 处理消息
4. 提交交易。
5. 转到1。

用一颗石头杀死两只鸟的另一种方法是在检索过程中跳过对消息的处理，而只是将检索到的消息写入事务处理的数据存储中。 然后，有一个单独的线程（按时间戳顺序）从存储中检索消息并进行处理（单独的线程-=单独的事务）。