最全 @Transactional Spring 事务失效场景

前提知识

@Transactional--Spring--Spring2.0及后版本默认cglib--cglib是生成代理实现类的子类来交付spring托管,所以声明式注解也就是使用@Transactional的方式来控制事务模式本质上是产生一个代理来执行,且这个代理还是Spring来生成的,所以@Transactional必须依托spring容器来进行工作的。

Spring事务传播策略

从英文命名理解Spring事务传播机制@Transactional解释

事务失效的场景

失效1:@Transactional 加在接口上

所以cglib无法生产子类,那么就无法托管到spring;

失效2:@Transactional 加在了final或者static上

cglib生产的子类无法继承原来的final或者static,所以cg代理子类会缺失对应的方法或者参数;

失效3:类方法内部调用

比如

classA{

@Transactional a(){

b();

}

@Transactional b() {

{

}

最后执行的方式是cg的代理方法,假设为A’

Class A’{

a(){

b();

}

}

A’中的a方法是直接调用的b方法的,而不是调用Transactional替b生成的事务代理方法,所以b事务直接失效;

解法:

@Compoent

class A{

@Transactional a(){

Spring_a.b();

}

1使用自我注入的方法,让A的cg代理类中a方法调用b时候,使用的是cg代理类来调用b

2通过AopContext.currentProxy()获取代理对象 道理类似于方式1,就是为了通过获取代理类来访问内部方法

失效4:当前的类没有托管给Spring

transaction是依托spring所管理的类而再次生产事务代理的,所以transaction 的前提就是当前类受spring托管;

失效5:非public修饰的方法

不支持非public修饰的方法进行事务管理,这是transactional代理中实现所规定的;

失效6:多线程调用

因为事务是与当前线程绑定的,所以多线程中的事务没办法保证生效,在多线程环境下,事务的信息都是独立的,将会导致Spring在接管事务上出现差异;

Demo:

主线程A调用线程B保存Id为1的数据,然后主线程A等待线程B执行完成再通过线程A查询id为1的数据。

这时你会发现在主线程A中无法查询到id为1的数据。因为这两个线程在不同的Spring事务中,本质上会导致它们在Mysql中存在不同的事务中。

Mysql中通过MVCC保证了线程在快照读时只读取小于当前事务号的数据,在线程B显然事务号是大于线程A的,因此查询不到数据。

失效7:使用的数据库不支持事务;

失效8:MVC框架下未开启事务,springboot中默认开启的;

失效9:Spring提供的事务抵抗机制

Spring支持了7种事务传播机制,其中不支持事务的传播机制为:PROPAGATION_SUPPORTS,PROPAGATION_NOT_SUPPORTED,PROPAGATION_NEVER,如果配置了这三种传播方式的话,在发生异常的时候,事务是不会回滚的;

失效10:rollbackFor属性设置错误

建议使用 @Transactional(rollbackFor = Exception.class)的方式进行全异常捕获;

失效11:异常被内部catch

异常被内部catch,捕捉不到,导致事务回滚失败;

Demo:

UserService

UserService1

如上代码UserService调用了UserService1中的方法,并且捕获了UserService1中抛出的异常。你将能看到控制台出现这样一个报错:org.springframework.transaction.UnexpectedRollbackException: Transaction rolled back because it has been marked as rollback-only默认情况下标注了@Transactional注解的方法的事务传播机制是REQUIRED,它的特性是支持当前事务,也就说加入当前事务。

我们在UserService中开始事务,然后再UserService1中抛出异常回滚UserService中的事务,将其标记为只读。但是在UserSevice中我们捕获了异常,此时UserService上的事务认为正常提交事务。最后在提交时发现事务只读,已经被回滚,则抛出了上述异常。因此这里如果需要对特定的异常进行捕获处理,记得再次将异常抛出,让最外层的事务感知到。

失效12:嵌套事务

上面是我想同时回滚UserService与UserService1。但是也会有这种场景只想回滚UserService1中报错的数据库操作,不影响主逻辑UserService中的数据落库。有两种方式可以实现上述逻辑:1.直接在UserService1内的整个方法用try/catch包住2.在UserService1使用Propagation.REQUIRES_NEW传播机制。

失效13:多线程

由于@Transactional是通过检测当前线程是否存在事务来对应做出策略决策的(具体实现在TransactionSynchronizationManager.class 附近,底层是 ThreadLocal),所以当在方法中手动创建线程来执行逻辑的时候,该新线程并没有交付 TransactionSynchronizationManager,当然@Transactional的行为也会受到影响,影响常常表现为事务失效,比如新线程执行异常但是@Transactional是捕获不到这个异常的,毕竟这个新线程没有交付Manager管理,甚至都没有交付给spring容器。解决:把异步逻辑单独开个方法 同时使用@Transactional 与 @Asyn。

  • 17
    点赞
  • 20
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
@Transactional注解失效场景有以下几种情况: 1. 异常被catch并处理: 当一个使用@Transactional注解标记的方法中发生异常时,如果异常被catch并在方法内部进行了处理,那么事务将不会回滚。这是因为Spring默认只会对未被捕获的异常进行回滚处理。 2. 事务方法内部调用其他事务方法: 如果一个使用@Transactional注解标记的方法内部调用了另一个使用@Transactional注解标记的方法,而内部方法没有抛出异常,则外部方法的事务将无效。原因是Spring默认使用了基于代理的事务机制,而代理是通过AOP实现的。在同一个类中,使用@Transactional注解标记的方法调用其他使用@Transactional注解标记的方法,事务失效。 3. 基于自调用的事务: 当一个使用@Transactional注解标记的方法内部调用了自身(即自循环),而且没有使用代理的方式进行调用,事务也会失效。这是因为代理是通过AOP实现的,自调用会绕过代理,导致事务无法生效。 4. 异步方法: 在使用Spring的异步方法时,如果在异步方法内部使用了@Transactional注解标记的方法,事务将无效。这是因为异步方法会在一个新的线程中执行,而事务是基于线程的。因此,在异步方法中使用事务注解是无效的。 5. protected或private方法: 当使用@Transactional注解标记的方法是protected或private修饰的时候,事务也会失效。尽管没有报错,但事务并不会起作用。这是一个常见的错误点,需要特别注意。 综上所述,需要注意以上情况,以确保@Transactional注解的正确使用和事务的生效。如果遇到上述场景,可以考虑使用其他方式来实现事务控制,如编程式事务管理或通过代理对象调用。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值