我认为使用JMS的很多(我的情况下是Spring)应用程序可能会遵循以下工作流程：
Database A ===> Producer ===> JMS Queue ===> Consumer ===> Database B
然后可靠性是一个问题.假设当数据库A中的数据记录应始终标记为已传递时,如果消息包含数据记录,则会真正使用数据记录,并将数据保留在数据库B中.然后有问题：
>据我所知,目前JMS协议没有定义任何从消费者向生产者发送确认的功能,而只定义为MOM,因此实际的消费者对生产者确认方法因JMS提供者而异.那么这是否意味着没有办法为这种确认开发一种可以适用于所有JMS产品(ActiveMQ,WebSphere MQ和Jboss MQ)的机制？
>考虑停电的情况,然后它是否会使队列中的消息消失,所以需要重新发送？或者不同的JMS产品可以获取剩余的内容,因为消息是序列化的,因此丢失的消息只能由事务管理或异步/同步配置引起,而不是因为应用程序服务器已关闭？
各种机制确保可靠性：
>第一个是队列中消息的持久性(队列和消息必须标记为持久性,这是默认值),以确保在系统中断时不会丢失消息.
>然后您有确认和重试策略,消息将保留在队列中,直到消费者确认它,并且在交易会话的情况下,将重新传递,直到消费者有效地处理消息或达到最大重试.然后可以将失败的消息重定向到死信队列以进行分析.
为了确保两个数据源之间的一致性,您必须至少在生产者端使用XA事务(事务数据库A和JMS队列中至少隐含了2个资源),以保证消息不会发布到队列,如果数据库A中的提交失败,或者如果队列中的帖子失败,则不会更新数据库.消息消耗也应该进行处理以确保在回滚的情况下重新传递.
事务边界永远不会同时包含使用者和生产者,因为它与消息传递系统的异步性质相冲突,在消费者处理消息之前你无法锁定生产者端的资源,因为你无法保证什么时候会消息发生.
注意：如果您的数据库不支持XA(或提高性能),并且如果事务中只隐含了2个资源(数据库和JMS队列),您可以查看Logging Last Resource Transaction Optimization
