多线程JMS代码:CLIENT_ACKNOWLEDGE或交易会话 [英] Multithreaded JMS code : CLIENT_ACKNOWLEDGE or transacted session

问题描述

已编辑的问题:我正在研究多线程JMS接收者和发布者代码(独立的多线程Java应用程序). MOM是MQSonic. 从队列接收XML消息，调用存储过程(执行需要70秒)，并在90秒内将响应发送到Topic. 当代理关闭或应用程序按计划关闭时，我需要处理一个条件.也就是在这种情况下，从Queue接收消息并在Java中对其进行处理，与此同时Queue和Topic都将关闭.然后，要处理那些不在队列中且未发送到主题但在Java内存中的消息，我有以下选择:

Edited Question : I am working on a multithreaded JMS receiver and publisher code (stand alone multithreaded java application). MOM is MQSonic. XML message is received from a Queue, stored procedures(takes 70 sec to execute) are called and response is send to Topic within 90 sec. I need to handle a condition when broker is down or application is on scheduled shutdown. i.e. a condition in which messages are received from Queue and are being processed in java, in the mean time both Queue and Topic will be down. Then to handle those messages which are not on queue and not send to topic but are in java memory, I have following options:

(1)创建CLIENT_ACKNOWLEDGE会话为: connection.createSession(false，javax.jms.Session.CLIENT_ACKNOWLEDGE) 在这里，我仅在成功完成事务(存储过程)之后确认消息

(1) To create CLIENT_ACKNOWLEDGE session as : connection.createSession(false, javax.jms.Session.CLIENT_ACKNOWLEDGE) Here I will acknowledge message only after the successful completion of transactions(stored procedures)

(2)要使用事务处理会话，即connection.createSession(true，-1).在这种方法中，由于事务(存储过程)中的某些异常，消息被回滚并重新传递.它们一次又一次地回滚，并一直持续到我终止该程序为止.我可以限制从队列重新发送jms消息的次数吗?

(2) To use transacted session i.e., connection.createSession(true, -1). In this approach because of some exception in transaction (stored procedure) the message is rolled back and Redelivered. They are rolled back again and again and continue until I kill the program. Can I limit the number of redelivery of jms messages from queue?

在上述两种方法中，哪一种更好?

Also in above two approached which one is better?

推荐答案

接口progress.message.jclient.ConnectionFactory具有方法setMaxDeliveryCount(java.lang.Integer value)，您可以在其中设置将消息重新发送到MessageConsumer的最大次数.当达到此次数时，它将被移至SonicMQ.deadMessage队列.

The interface progress.message.jclient.ConnectionFactory has a method setMaxDeliveryCount(java.lang.Integer value) where you can set the maximum number of times a message will be redelivered to your MessageConsumer. When this number of times is up, it will be moved to the SonicMQ.deadMessage queue.

您可以在第210页的《 Sonic MQ应用程序编程指南》(版本7.6)中进行检查.

You can check this in the book "Sonic MQ Application Programming Guide" on page 210 (in version 7.6).

关于您的问题哪个更好...这取决于存储过程是否打算执行多次.如果存在问题，则应使用跨JMS队列和数据库的事务(Sonic支持XA事务).如果您不介意执行多次，那么当您发现代理已关闭(很可能是您尝试确认该消息)时，我将不确认消息并中止处理.这样，如果第一个处理器在连接失败后无法处理该消息，则另一个处理器能够处理该消息.

As to your question about which is better... that depends on whether the stored procedure minds being executed multiple times. If that is a problem, you should use a transaction that spans the JMS queue and the database both (Sonic has support for XA transactions). If you don't mind executing multiple times, then I would go for not acknowledging the message and aborting the processing when you notice that the broker is down (when you attempt to acknowledge the message, most likely). This way, another processor is able to handle the message if the first one is unable to do so after a connection failure.

如果消息需要花费可变的时间来处理，则您可能还需要查看Sonic JMS会话的SINGLE_MESSAGE_ACKNOWLEDGE模式.通常，在消息上调用acknowledge()也会确认之前出现的所有消息.如果您不按顺序处理它们，那不是您想要的事情.在单消息确认模式下(不是JMS标准)，acknowledge()仅确认在其上被调用的消息.

If the messages take variable time to process, you may also want to look at the SINGLE_MESSAGE_ACKNOWLEDGE mode of the Sonic JMS Session. Normally, calling acknowledge() on a message also acknowledges all messages that came before it. If you're processing them out of order, that's not what you want to happen. In single message acknowledge mode (which isn't in the JMS standard), acknowledge() only acknowledges the message on which it is called.

这篇关于多线程JMS代码:CLIENT_ACKNOWLEDGE或交易会话的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！