关于 JMS 中的 Session.rollBack()
全部， 我是 JMS 新手，我对 JMS 中的 Session.rollBack() 方法有疑问。 AFAIK，此方法用于在使用 *SESSION_TRANSACTED* 确认模式时回滚会话对 JMS 服务器的所有操作（发送/接收）。现在假设我在接收/处理操作的 catch 块中调用此方法（合理吗？），告诉 JMS 服务器重新传递消息进行处理，但即使重新传递消息，处理仍然会引发相同的异常，从而导致JMS服务器再次重新传送消息，因此看起来是一个无限的过程。如何处理这个问题？或者还有其他专门为此设计的 JMS 功能吗？提前致谢！
All,
i am new to JMS and i have a question about Session.rollBack() method in JMS. AFAIK, this method is used to roll back all operations to JMS server (sending/receiving) by the session when using *SESSION_TRANSACTED* acknowledge mode. Now suppose I am calling this method in a catch block of a receiving/processing operation (is reasonable?), to tell JMS server to redeliver the message for processing, But even if it is redelivered the processing still throws the same exception which cause the JMS server to redeliver the message again, so it seems a infinite process. How to handle this problem? or are there any other JMS features that is designed for it? Thanks in advance!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
JMS 中的回滚方法将回滚该“事务”中发送和接收的任何消息。这里的事务是 JMS 会话的本地事务。
重新交付是否会导致问题实际上取决于异常发生的原因。如果是由于某些暂时性问题造成的，则可以重新投递。如果您遇到的问题是一旦发生就会一直发生（一个例子是 JMS TextMessage，其正文应该包含 XML，但实际上却没有）。
JMS API 本身没有提供任何解决方案。这通常由 JMS 提供者负责，其行为方式取决于您使用哪一个。例如，WebSphere MQ 将重新传送至可配置的最大值，此时它将将其移至不良消息队列。 WebSphere Application Server 中的服务集成总线具有类似的行为。我建议您查阅 JMS 提供程序文档来准确确定它在这种情况下的行为方式。
如果您在应用程序服务器中运行，回滚通常不会执行任何操作，因为应用程序服务器将为您管理事务。
The rollback method in JMS will rollback any message sends and receives in that "transaction". Transaction here is local to the JMS session.
Whether a redelivery will cause a problem really depends on why the exception occurred. If it was due to some transitory issue then a redelivery may work. If you have the kind of problem that is once it occurs will always occur (an example of this would be a JMS TextMessage whose body should contain XML, but doesn't).
The JMS API doesn't provide any solution to this itself. This is typically taken care of by the JMS provider and how it behaves will depend on which one you use. WebSphere MQ for instance will redeliver up to a configurable maximum at which point it will move it off to a queue for bad messages. The Service Integration Bus in WebSphere Application Server has similar behaviour. I suggest you consult your JMS provider documentation to determine exactly how it behaves in this situation.
If you are running in an application server rollback typically doesn't do anything because the application server will be managing transactions for you.