本文共xxxx字&＃xff0c;将列举Spring事务失效的几种实际场景&＃xff0c;帮助大家避免和发现此类问题&＃xff0c;并保证事务的正常启用。
前言
Spring可谓是目前最流行的Java开发框架了&＃xff0c;除了为开发者提供便利和强大的开发方式外&＃xff0c;它也整合了数据库的事务功能&＃xff0c;形成了一套事务管理的框架。
一般情况下&＃xff0c;在SpringBoot强大的注解模式下&＃xff0c;我们都是采用&＃64;Transaction的注解进行事务在方法层面的开启。
但很多情况下&＃xff0c;会发现&＃xff0c;咦&＃xff0c;自己明明配置了注解&＃xff0c;也启动了配置&＃xff0c;为何事务不生效呢&＃xff1f;
下面&＃xff0c;我们就来列举下常见的几种事务失效场景。
事务失效场景总结
当使用的数据库引擎不支持事务的时候&＃xff0c;那么Spring即使开启了事务&＃xff0c;也不会生效&＃xff0c;要知道&＃xff0c;Spring的事务管理实际上是对数据库事务的一次封装。
这里以 MySQL 为例&＃xff0c;其 MyISAM 引擎是不支持事务操作的&＃xff0c;InnoDB 才是支持事务的引擎&＃xff0c;一般要支持事务都会使用 InnoDB。
从 MySQL 5.5.5 开始的默认存储引擎是&＃xff1a;InnoDB&＃xff0c;之前默认的都是&＃xff1a;MyISAM&＃xff0c;所以这点要值得注意&＃xff0c;底层引擎不支持事务再怎么搞都是白搭。
当程序引用的数据源&＃xff0c;没有配置事务管理器时&＃xff0c;便相当于没有事务管理&＃xff0c;自然也不会生效
&＃64;Bean
public PlatformTransactionManager transactionManager(DataSource dataSource) {
return new DataSourceTransactionManager(dataSource);
}
Spring官方表示&＃xff1a;&＃64;Transaction注解需要用在public方法上&＃xff0c;否则事务不会失效&＃xff0c;如果要用在非 public 方法上&＃xff0c;可以开启AspectJ的代理模式。
也就是说使用了&＃64;Transaction注解的方法&＃xff0c;其所在的类没有被Spring创建为一个Bean&＃xff0c;此时是不会被Spring所管理的&＃xff0c;那么事务自然也就失效了。
之前有一篇文章讲述了事务传播机制&＃xff0c;其中有不支持事务的传播机制&＃xff0c;比如说NOT_SUPPORTED。也就是说&＃xff0c;当我们在&＃64;Transaction注解中&＃xff0c;使用了不支持事务的传播机制时&＃xff0c;此时事务是不会生效的。
比如&＃xff1a;
&＃64;Service
public class TestServiceImpl implements TestService {
&＃64;Transactional(propagation &＃61; Propagation.NOT_SUPPORTED)
public void testTran(String arg) {
// doSomething
}
}
可见&＃xff0c;当配置属性propagation为Propagation.NOT_SUPPORTED时&＃xff0c;表示主动不以事务运行。
Spring的事务管理&＃xff0c;实际上就是通过代理&＃xff0c;在配置了&＃64;Transaction的方法前后拦截&＃xff0c;在捕获到对应类型的异常时进行回滚。那么如果我们在方法里进行手动的try..catch&＃xff0c;并且将捕获到的异常给吃了&＃xff0c;那么Spring代理便无法得知方法调用的异常情况&＃xff0c;就无法进行事务异常时的回滚操作。
比如&＃xff1a;
&＃64;Service
public class TestServiceImpl implements TestService {
&＃64;Transactional
public void testTran(String arg) {
try{
// doSomething
} catch (Exception e){
// 捕获处理不抛出
}
}
Spring的事务异常回滚&＃xff0c;有自己制定的异常类型&＃xff0c;当满足了条件才会进行回滚&＃xff0c;默认的异常类型为RuntimeException&＃xff0c;那么此时如果我们抛出了非这个类型的异常时&＃xff0c;同样是不会进行回滚的。
比如&＃xff1a;
&＃64;Service
public class TestServiceImpl implements TestService {
&＃64;Transactional
public void testTran(String arg) {
try{
// doSomething
} catch (Exception e){
throw new Exception(....)
}
}
那么如何解决这个问题呢&＃xff0c;我们可以通过配置&＃64;Transaction里的rollbackFor属性&＃xff0c;指定为Exception.class来解决问题&＃xff0c;但建议针对业务性异常&＃xff0c;最好自己在程序里创建继承于RuntimeException的异常类&＃xff0c;并显式抛出。
来看下下面这个代码&＃xff1a;
&＃64;Service
public class TestServiceImpl implements TestService {
public void test(String arg){
this.testTran(arg);
}
&＃64;Transactional
public void testTran(String arg) {
try{
// doSomething
} catch (Exception e){
throw new RuntimeException(....)
}
}
当我们调用test()这个没有加事务的方法的时候&＃xff0c;其调用的testTran()方法若是出现了异常&＃xff0c;此时testTran()所启用的事务会回滚吗&＃xff1f;
答案是不会的。
再看下面这个代码&＃xff1a;
&＃64;Service
public class TestServiceImpl implements TestService {
&＃64;Transactional
public void test(String arg){
this.testTran(arg);
}
&＃64;Transactional(propagation &＃61; Propagation.REQUIRES_NEW)
public void testTran(String arg) {
try{
// doSomething
} catch (Exception e){
throw new RuntimeException(....)
}
}
我们为test()方法开启事务&＃xff0c;并且对其调用的方法&＃xff0c;我们配置传播属性为——创建一个新事务。
此时这个新开的事务会生效吗&＃xff1f;
答案也是不会的。
之所以不会&＃xff0c;是因为它们发生了自身调用。这个问题可谓是许多人都会碰到的一种失效情况&＃xff0c;大多数方法&＃xff0c;我们会出现调用的情况&＃xff0c;当调用了自身类的方法时&＃xff0c;由于此时没有经过Spring的代理类&＃xff0c;也就是内部调用了事务方法&＃xff0c;这种情况将导致该调用方法的事务失效。
那么如何解决自身调用出现的事务失效问题呢&＃xff1f;
- 一种是在类中再注入自己&＃xff0c;调用时通过注入的这个bean来进行方法调用&＃xff0c;此时会由Spring的代理类进行方法调用&＃xff0c;事务将生效&＃xff0c;缺点是不优雅。
- 一种是将调用方法写到另一个bean中&＃xff0c;注入该bean再去调用&＃xff0c;缺点无疑是将相同业务的代码拆分&＃xff0c;导致复杂度增高。
- 一种是通过AopContext.currentProxy()来获取当前代理&＃xff0c;转换为当前类后进行方法调用。比如
((TestService)AopContext.currentProxy()).testTran(arg);
这种方式是官方为我们提出的解决方案&＃xff0c;也建议使用这种方案&＃xff0c;注意&＃xff0c;使用AopContext.currentProxy()是需要将expose-proxy设置为true才能生效的。
Tip
以上列举出来了8种常见的事务失效场景和部分解决方案&＃xff0c;其中最常见的便是“异常不抛出”、“异常类型不正确”以及“自身调用”这三个问题。
京公网安备 11010802041100号