在我们的应用程序中，我们收到来自JMS主题的消息。
我们使用消息（持久订阅者和JMS会话被处理，大量开销），因为消息保留在JMS服务器上，直到事务提交/结束。我们指定交易的原因是
我们正在使用缓存（hibernate）技术和事务来使用它。因此，我们使用两个事务，一个是JMS tx，一个是缓存技术tx。当我们使用消息时，我们希望在提交消息并将确认发送到JMS之前发生全部或全部事件。缓存tx将首先提交，然后立即JMS tx将提交下一个并且消息被确认，否则，tx将被回滚并且消息将被重放。我们当前正在重播消息3次，然后如果异常仍然发生，那么我们将消息发送到不可处理的队列。
这很好用，直到许多消息同时到达JMS并且需要同时由我们的系统处理。
我想知道当你遇到这种情况时你做了什么。因为维护持久订阅和事务处理会话是JMS服务器的重大开销，并且会耗尽服务器的性能。
答案 0 :(得分：1)
主题的消息排序未在JMS规范中指定，因此官方的答案是它是特定于JMS实现的。话虽如此，除非特别重写以做其他事情，否则我认为消息将以FIFO顺序传递。
对于事务，我建议您考虑实现两个阶段提交XA事务，这样您就不需要两个单独的事务。如果您的缓存实现支持XA，则JMS和Cache（和DB）事务将是同一个。
通常我发现对于这些类型的事务处理消息，如果必须使用事务处理消息，那么挤出性能的最佳方法是在一个事务中处理尽可能多的消息：< / p>
另一种杀死2只鸟的方法是在检索期间跳过消息的处理，并将检索到的消息简单地写入事务数据存储。然后让一个单独的线程从存储中检索消息（按时间戳顺序）并处理它们（单独的线程 - =单独的事务）。