JMS与数据库事务

发送消息时的事务

THREAD系统中使用spring的JmsTemplate组件来发送消息。这是我们THREAD系统中的配置:


<beanid="newJmsTemplate"class="org.springframework.jms.core.JmsTemplate">

<propertyname="connectionFactory"ref="jmsConnectionFactory"/>

<propertyname="sessionTransacted"value="true"/>

<propertyname="explicitQosEnabled"value="${activemq.explicitQosEnabled}"/>

<propertyname="timeToLive"value="86400000"/>

bean>

其中“”这一行就是发送消息时的事务配置。有了这个配置之后,Jms消息发送就与事务绑定上了。

而它在事务中的行为还与transactionManager有关。这是我们THREAD系统中的transactionManager配置:


<beanid="transactionManager"

class="org.springframework.orm.hibernate4.HibernateTransactionManager">

<propertyname="sessionFactory"ref="sessionFactory"/>

<propertyname="nestedTransactionAllowed"value="true"/>

<propertyname="globalRollbackOnParticipationFailure"value="false"/>

bean>

在这个transactionManager配置下,Jms消息会在afterCommit()操作中提交。如下图所示。

根据网上的文章,如果要保证jms操作和数据库操作真正做到“同生共死”,必须使用JTATransactionManager。但是这个东东的性能一直是个问题。


<tx:jta-transaction-manager/>

接收消息时的重发机制

接收消息后的重发机制与数据库事务之间的关系,并没有像发送消息时那样严格的绑定在一起。也就是说,接收消息后是否重试与数据库事务没有必然的关系。

一般来说,做到以下两点,就可以实现重试。

首先,在listener的配置中增加“acknowledge="transacted"”,如下所示。


<jms:listener-containerdestination-type="queue"

concurrency="4"acknowledge="transacted"connection-factory="connectionFactory">

<jms:listenerdestination="queue.thread.autopay"ref="autoPayListener"/>

jms:listener-container>

第二,当消息处理失败后,抛出异常。


@Override

publicvoidonMessage(Message message) {

try{

// 省略业务处理代码

catch(Exception e) {

// 省略日志、监控邮件等代码

// 抛出异常,让MQ重发一次消息。

throwinstanceofRuntimeException ? (RuntimeException) e

newRuntimeException(e);

}

}

默认的消息重发规则配置在org.apache.activemq.RedeliveryPolicy类中。从代码上看,默认会重发6次。如果需要修改默认配置,可以参考THREAD中spring-modules.xml文件中的配置:


<amq:connectionFactoryid="connectionFactory"brokerURL="tcp://${jms.url}:61616">

<amq:redeliveryPolicyMap>

<amq:redeliveryPolicyMap>

<amq:defaultEntry>

<amq:redeliveryPolicymaximumRedeliveries="5"initialRedeliveryDelay="30000"/>

amq:defaultEntry>

<amq:redeliveryPolicyEntries>

<amq:redeliveryPolicyqueue="queue.thread.autopay"maximumRedeliveries="5"

initialRedeliveryDelay="10000"/>

<amq:redeliveryPolicyqueue="queue.thread.instantUnionpay"maximumRedeliveries="5"

initialRedeliveryDelay="90000"/>

amq:redeliveryPolicyEntries>

amq:redeliveryPolicyMap>

amq:redeliveryPolicyMap>

amq:connectionFactory>

如果重试次数超过上限,MQ会将消息转到另一个“投递失败队列”(Dead Letter Queue)中。“投递失败队列”的名称一般就是“DLQ.原队列名”。

时间: 2025-01-11 21:01:10

JMS与数据库事务的相关文章

如何将一个操作“绑定到数据库事务上”

摘要 spring-cache简介 基本机制 事务上下文中的问题 将操作绑定到数据库事务上 spring-cache的相关实现 TransactionSynchronizationManager和TransactionSynchronizationAdapter 事务相关操作注册与回调流程 其它应用 摘要 在开发中,我们常常会遇到(或者需要)把一些操作"绑定到数据库事务上".也就是说,如果数据库事务成功提交,则执行这个操作:如果数据库事务回滚,则不执行这个操作(或者执行另一个操作).

学习ActiveMQ(七):JMS消息的事务管理

Spring提供了一个JmsTransactionManager用于对JMS ConnectionFactory做事务管理.这将允许JMS应用利用Spring的事务管理特性.JmsTransactionManager在执行本地资源事务管理时将从指定的ConnectionFactory绑定一个ConnectionFactory/Session这样的配对到线程中.JmsTemplate会自动检测这样的事务资源,并对它们进行相应操作. 在Spring整合JMS的应用中,如果我们要进行本地的事务管理的话

数据库事务的四大特性和事务隔离级别

Reference: [1] http://www.cnblogs.com/fjdingsd/p/5273008.html [2] http://blog.csdn.net/fg2006/article/details/6937413 数据库事务四大特性 如果一个数据库声称支持事务的操作,那么该数据库必须要具备以下四个特性: ⑴ 原子性(Atomicity) 原子性是指事务包含的所有操作要么全部成功,要么全部失败回滚,这和前面两篇博客介绍事务的功能是一样的概念,因此事务的操作如果成功就必须要完全

数据库事务隔离级别

数据库事务的隔离级别有4个,由低到高依次为Read uncommitted.Read committed.Repeatable read.Serializable,这四个级别可以逐个解决脏读.不可重复读.幻读这几类问题. √: 可能出现    ×: 不会出现   脏读 不可重复读 幻读 Read uncommitted √ √ √ Read committed × √ √ Repeatable read × × √ Serializable × × × 注意:我们讨论隔离级别的场景,主要是在多个

数据库-事务和锁

事务 所谓事务是用户定义的一个数据库操作系列,这些操作要么全部执行,要么全部不执行,是一个不可分割的工作单位.例如在关系数据库中,一个事务可以是一条sql语句.一组sql语句或整个程序. 给个栗子: 小IT在网上购物,其付款过程至少包括以下几步数据库操作: 更新客户所购商品的库存信息: 生成订单并且保存到数据库: 更新用户相关信息,例如购物数量等: 正常情况下,操作顺利进行,最终交易成功,那么与交易相关的所有数据库信息也成功更新.但是,如果在这一系列过程中任何一个环节出了差错,例如在更新商品库存

数据库事务的四大特性ACID

本篇讲诉数据库中事务的四大特性(ACID),并且将会详细地说明事务的隔离级别. 如果一个数据库声称支持事务的操作,那么该数据库必须要具备以下四个特性: ⑴ 原子性(Atomicity) 原子性是指事务包含的所有操作要么全部成功,要么全部失败回滚,所以事务的操作如果成功就必须要完全应用到数据库,如果操作失败则不能对数据库有任何影响.为了实现原子性,需要通过日志:将所有对数据的更新操作都写入日志,如果一个事务中的一部分操作已经成功,但以后的操作,由于断电/系统崩溃/其它的软硬件错误而无法继续,则通过

数据库事务的隔离级别

数据库事务的隔离级别有4个,由低到高依次为Read uncommitted.Read committed.Repeatable read.Serializable,这四个级别可以逐个解决脏读.不可重复读.幻读这几类问题. √: 可能出现    ×: 不会出现   脏读 不可重复读 幻读 Read uncommitted √ √ √ Read committed × √ √ Repeatable read × × √ Serializable × × × 注意:我们讨论隔离级别的场景,主要是在多个

数据库事务测试以及级联更新级联删除

数据库事务 start transaction; #开始事务 insert into gzb(gz)values(5000); insert into gzb(gz)values(6000); insert into gzb(gz)values(7000); insert into gzb(gz)values(8000); /*执行事务,并查看是否添加成功数据*/ commit; # commit数据,查看表中数据是否提交 rollback; #数据库回滚 级联更新,级联删除 主要通过两种方式

数据库事务课上代码

1 <?xml version="1.0" encoding="utf-8"?> 2 <LinearLayout xmlns:android="http://schemas.android.com/apk/res/android" 3 xmlns:tools="http://schemas.android.com/tools" 4 android:layout_width="match_parent