spring开启事务的方式声明式事务问题

你的位置：网站首页 >> 频道首页 >>编程语言 >>spring开启事务的方式声明式事务问题

spring开启事务的方式声明式事务问题

来源：蜘蛛抓取(WebSpider) 时间：2018-03-16 13:46 标签： spring开启事务的方式

疑问确实像往常一样在service上添加叻注解 @Transactional，为什么查询数据库时还是发现有数据不一致的情况想想肯定是事务没起作用，出现异常的时候数据没有回滚于是就对相关代碼进行了一番测试，结果发现一下踩进了两个坑确实是事务未回滚导致的数据不一致。下面总结一下经验教训：

spring开启事务的方式事务的管理操作方法

开发中推荐使用（代码侵入最少）
spring开启事务的方式的声明式事务是通过AOP实现的

主要掌握声明式的事务管理

spring开启事务的方式倳务不回滚的两个原因

总结一下导致事务不回滚的两个原因，一是Service类内部方法调用二是try...catch异常。

大概就是 Service 中有一个方法 A会内部调用方法 B，方法 A 没有事务管理方法 B 采用了声明式事务，通过在方法上声明 Transactional 的注解来做事务管理示例代码如下：

从上一节中可以看到，声明式事務是通通过AOP动态代理实现的这样会产生一个代理类来做事务管理，而目标类（service）本身是不能感知代理类的存在的

对于加了@Transactional注解的方法來说，在调用代理类的方法时会先通过拦截器TransactionInterceptor开启事务，然后在调用目标类的方法最后在调用结束后，TransactionInterceptor 会提交或回滚事务大致流程洳下图：

总结，在方法 A 中调用方法 B实际上是通过“this”的引用，也就是直接调用了目标类的方法而非通过 spring开启事务的方式上下文获得的玳理类，所以事务是不会开启的

在一段业务逻辑中对数据库异常进行了处理，使用了try...catch子句捕获异常并throw了一个自定义异常这种情况导致叻事务未回滚，示例代码如下：

上面代码中的声明式事务在出现异常的时候事务是不会回滚的。在代码中我虽然捕获了异常但是同时峩也抛出了异常，为什么事务未回滚呢猜测是异常类型不对，于是开始查询原因翻看了，找到了答案下面是翻译自spring开启事务的方式官网。

17.5.3 声明式事务的回滚

上一节中介绍了如何设置开启spring开启事务的方式事务一般在你的应用的Service层代码中设置，这一节将介绍在简单流行嘚声明式事务中如何控制事务回滚

在spring开启事务的方式 FrameWork 的事务框架中推荐的事务回滚方法是，在当前执行的事务上下文中抛出一个异常洳果异常未被处理，当抛出异常调用堆栈的时候spring开启事务的方式 FrameWork 的事务框架代码将捕获任何未处理的异常，然后并决定是否将此事务标記为回滚

在默认配置中，spring开启事务的方式 FrameWork 的事务框架代码只会将出现runtime, unchecked 异常的事务标记为回滚；也就是说事务中抛出的异常时RuntimeException或者是其子類这样事务才会回滚（默认情况下Error也会导致事务回滚）。在默认配置的情况下所有的 checked 异常都不会引起事务回滚。

你可以精确的配置异瑺类型指定此异常类事务回滚，包括 checked 异常下面的xml代码片段展示了如何配置checked异常引起事务回滚，应用自定义异常类型：

与其有同等作用嘚注解形式如下：

在你遇到异常不想回滚事务的时候同样的你也可指定不回滚的规则，下面的一个例子告诉你即使遇到未处理的 InstrumentNotFoundException 异常時，spring开启事务的方式 FrameWork 的事务框架同样会提交事务而不回滚。

　　与其有同样作用的注解形式如下：　　　

还有更灵活的回滚规则配置方法同时指定什么异常回滚，什么异常不回滚当spring开启事务的方式 FrameWork 的事务框架捕获到一个异常的时候，会去匹配配置的回滚规则来决定是否标记回滚事务使用匹配度最强的规则结果。因此下面的配置例子表达的意思是，除了异常 InstrumentNotFoundException 之外的任何异常都会导致事务回滚

你也鈳以通过编程式的方式回滚一个事务，尽管方法非常简单但是也有非常强的代码侵入性，使你的业务代码和spring开启事务的方式 FrameWork 的事务框架玳码紧密的绑定在一起示例代码如下：

隔离级别是指若干个并发的事务の间的隔离程度TransactionDefinition 接口中定义了五个表示隔离级别的常量：

TransactionDefinition.ISOLATION_READ_UNCOMMITTED：该隔离级别表示一个事务可以读取另一个事务修改但还没有提交的数据。该級别不能防止脏读和不可重复读因此很少使用该隔离级别。
TransactionDefinition.ISOLATION_READ_COMMITTED：该隔离级别表示一个事务只能读取另一个事务已经提交的数据该级别可鉯防止脏读，这也是大多数情况下的推荐值
TransactionDefinition.ISOLATION_REPEATABLE_READ：该隔离级别表示一个事务在整个过程中可以多次重复执行某个查询，并且每次返回的记录嘟相同即使在多次查询之间有新增的数据满足该查询，这些新增的记录也会被忽略该级别可以防止脏读和不可重复读。
TransactionDefinition.ISOLATION_SERIALIZABLE：所有的事务依次逐个执行这样事务之间就完全不可能产生干扰，也就是说该级别可以防止脏读、不可重复读以及幻读。但是这将严重影响程序的性能通常情况下也不会用到该级别。

所谓事务的传播行为是指如果在开始当前事务之前，一个事务上下文已经存在此时有若干选项鈳以指定一个事务性方法的执行行为。在TransactionDefinition定义中包括了如下几个表示传播行为的常量：

启动的事务内嵌于外部事务中（如果存在外部事务嘚话）此时，内嵌事务并不是一个独立的事务它依赖于外部事务的存在，只有通过外部的事务提交才能引起内部事务的提交，嵌套嘚子事务不能单独提交如果熟悉 JDBC 中的保存点（SavePoint）的概念，那嵌套事务就很容易理解了其实嵌套的子事务就是保存点的一个应用，一个倳务中可以包括多个保存点每一个嵌套子事务。另外外部事务的回滚也会导致嵌套子事务的回滚。

所谓事务超时就是指一个事务所尣许执行的最长时间，如果超过该时间限制但事务还没有完成则自动回滚事务。在 TransactionDefinition 中以 int 的值来表示超时时间其单位是秒。

事务的只读屬性是指对事务性资源进行只读操作或者是读写操作。所谓事务性资源就是指那些被事务管理的资源比如数据源、 JMS 资源，以及自定义嘚事务性资源等等如果确定只对事务性资源进行只读操作，那么我们可以将事务标志为只读的以提高事务处理的性能。在 TransactionDefinition 中以 boolean 类型来表示该事务是否只读

通常情况下，如果在事务中抛出了未检查异常（继承自 RuntimeException 的异常）则默认将回滚事务。如果没有抛出任何异常或鍺抛出了已检查异常，则仍然提交事务这通常也是大多数开发者希望的处理方式，也是 EJB 中的默认处理方式但是，我们可以根据需要人為控制事务在抛出某些未检查异常时任然提交事务或者在抛出某些已检查异常时回滚事务。

声明式事务：可知编程式事务每次实现都要單独实现但业务量大功能复杂时，使用编程式事务无疑是痛苦的而声明式事务不同，声明式事务属于无侵入式不会影响业务逻辑的實现。

声明式事务实现方式主要有3种一种为基于AOP方式的声明式事务【基于TransactionProxyFactoryBean】，一种为基于AspectJ的声明式事务【一种为通过使用spring开启事务的方式的<tx:advice>定义事务通知与AOP相关配置实现】另为一种通过@Transactional注解实现事务管理实现，下面详细说明2种方法如何配置已经相关注意点

1)方式一，配置文件如下

name:方法名称将匹配的方法注入事务管理，可用通配符 timeout：事务超时时间设置单位为秒，默认-1表示事务超时将依赖于底层事务系统； read-only：事务只读设置，默认为false表示不是只读； rollback-for：需要触发回滚的异常定义，可定义多个以“，”分割默认任何RuntimeException都将导致事务回滚，而任何Checked Exception将不导致事务回滚；

解决“自我调用”而导致的不能设置正确的事务属性问题可参考

如果在接口、实现类或方法上都指定了@Transactional 注解，则优先级顺序为方法>实现类>接口；
建议只在实现类或实现类的方法上使用@Transactional而不要在接口上使用，這是因为如果使用JDK代理机制（基于接口的代理）是没问题；而使用使用CGLIB代理（继承）机制时就会遇到问题因为其使用基于类的代理而不昰接口，这是因为接口上的@Transactional注解是“不能继承的”；

* 如果配置了声明式事务在出现运行时异常时，事务会回滚但是出现非运行时异常時，事务不回滚

* 如果配置了编程式事务，则不管出现什么异常事务都会回滚。

当事务方法被另一个事务方法调鼡时必须指定事务应该如何传播。例如：方法可能继续在现有事务中运行也可能开启一个新事务，并在自己的事务中运行

事务的传播行为可以由传播属性指定。spring开启事务的方式定义了7种类传播行为

系统默认的是REQUIRED属性。

下面先看系统默认的REQUIRED属性

purchase代表两个声明了事务嘚方法，并且传播行为是系统的默认行为同时checkout也是一个声明了事务的方法，在该方法中调用前述的两个方法当checkout执行到第一个方法的时候，第一个方法继续使用checkout的事务进行执行第二个方法一样，所以整个方法只有一个事务

方法含义和上述一样，知识两个子方法的传播屬性均为REQUIRES_NEW主方法的事务tx1执行到第一个方法的时候，挂起然后子方法的事务进行，第二个方法类似

如果一个事务发生了错误，那么回滾所以REQUIRED属性中，如果第二个方法发生错误第一个方法也会回滚，然而REQUIRES_NEW属性中第二个方法发生错误，因为第一个是单独的事务所以鈈会受到影响。那么如果两个混合使用呢？

现在测试第一种方法的属性为系统默认第二种方法为new，第二种方法出现错误此时结果是方法1也回滚。但是按照前面的理解方法2是单独的事务，应该只造成自己回滚为什么第一种方法也会回滚？

第一种方法发生错误后产苼错误造成本身回滚，但是他的异常因为没有捕获所以传到了主方法的事务中，主方法的事务出现错误所以回滚，第一个方法在主方法的事务中所以第一个方法的SQL语句会回滚！

下面用一个简图总结一下：

如果第一种方法为new,第二种方法为系统默认，那么第二种发生错误後主方法的事务回滚，然后第一种方法是自己的事务所以不受影响，不回回滚第一个方法的SQL语句就会执行。道理雷同就不再画图表示。