解读@Transactional失效的几种情况
Spring事务管理方式
- 编码式事务管理:将事务控制代码编写在业务代码之中。
- 声明式事务管理:基于AOP(面向切面编程),事务管理与业务逻辑解耦。
声明式事务管理的两种实现:
- (1)在配置文件(xml)中配置。
- (2)基于@Transactional注解。
@Transactional使用起来方便,但也需要注意引起@Transactional失效的场景,本文总结了七种情况,下面进行逐一分析:
一、数据库本身不支持
MySql 的 MyISAM 引擎不支持回滚,如果需要自动回滚事务,需要将MySql的引擎设置成InnoDB;
二、注解的方法是否为public
//@Transactional注解在private方法上会失效 @Transactional private void deleteUser() throws MyException{ userMapper.deleteUserA(); int i = 1/0; userMapper.deleteUserB(); }
idea直接会给出提示Methods annotated with ‘@Transactional’ must be overridable ,原理很简单,private修饰的方式,spring无法生成动态代理,AOP代理分别在intercept()和invoke()方法判断是否进行事务拦截,这两个方法都会间接调用AbstractFallbackTransactionAttributeSource类的computeTransactionAttribute方法来获取事务控制的相关属性。
这其中有以下一段代码
/** * Same signature as {@link #getTransactionAttribute}, but doesn't cache the result. * {@link #getTransactionAttribute} is effectively a caching decorator for this method. * <p>As of 4.1.8, this method can be overridden. * @since 4.1.8 * @see #getTransactionAttribute */ protected TransactionAttribute computeTransactionAttribute(Method method, Class<?> targetClass) { // Don't allow no-public methods as required. if (allowPublicMethodsOnly() && !Modifier.isPublic(method.getModifiers())) { return null; } //... }
这段代码会导致no-public的方法无法进入事务控制,所以一定要确保自己需要进行事务控制的方法包含public修饰符。
三、异常处理不当
当异常被捕获后,并且没有再抛出,那么deleteUserA是不会回滚的,例如:
@Transactional public void deleteUser() { userMapper.deleteUserA(); try { int i = 1 / 0; userMapper.deleteUserB(); } catch (Exception e) { e.printStackTrace(); } }
异步虽然抛出了,但是抛出的是非RuntimeException类型的异常,依旧不会生效,例如:
@Transactional public void deleteUser() throws MyException{ userMapper.deleteUserA(); try { int i = 1 / 0; userMapper.deleteUserB(); } catch (Exception e) { throw new MyException(); } }
注解为事务范围的方法中,事务的回滚仅仅对于unchecked的异常有效。对于checked异常无效。也就是说事务回滚仅仅发生在,出现RuntimeException或Error的时候。通俗一点就是:代码中出现的空指针等异常,会被回滚。而文件读写、网络超时问题等,spring就没法回滚了。
解决方案:如果指定了回滚异常类型为Exception,那么就可以回滚Checked类型异常了。
@Transactional(rollbackFor = Exception.class)
java里面将派生于Error或者RuntimeException(比如空指针,1/0)的异常称为unchecked异常,其他继承自java.lang.Exception得异常统称为Checked Exception,如IOException、TimeoutException等
四、方法内部直接调用
如果先调用deleteUser(),那么deleteUserA()是不会回滚的,其原因就是@Transactional根本没生成代理,例如:
public void deleteUser() throws MyException{ deleteUser2(); // 事物失效 } @Transactional public void deleteUser2() throws MyException{ userMapper.deleteUserA(); int i = 1 / 0; userMapper.deleteUserB(); }
五、多数据源事物配置问题
项目中没有配置事务管理器,需要在配置类或者配置文件中配置,因为项目是多数据源的,所以要区别配置不同数据源的事务管理器,如下:
@Primary @Bean(name = "db1") public DataSource getDataSource() { return createDataSource(); } @Bean(name = "db1TransactionManager") public PlatformTransactionManager txManager(@Qualifier("db1") DataSource dataSource) { return new DataSourceTransactionManager(dataSource); } @Bean(name = "db2") public DataSource getDataSource() { return buildDataSource(); } @Bean(name = "db2TransactionManager") public PlatformTransactionManager txManager(@Qualifier("db2") DataSource dataSource) { return new DataSourceTransactionManager(dataSource); }
可以看到,两个事务管理器配置了不同的beanName,接下来只需要 在需要事务控制的位置加上该事务管理器的name就可以完美解决!
@Override @Transactional(value = "db1TransactionManager",rollbackFor = Exception.class) public int updateOrInsert(BaseRequest<BankTemplateDto> param) { ... }
六、新开启一个线程
如下的方式deleteUserA()也不会回滚,因为spring实现事务的原理是通过ThreadLocal把数据库连接绑定到当前线程中,新开启一个线程获取到的连接就不是同一个了,例如:
@Transactional public void deleteUser() throws MyException{ userMapper.deleteUserA(); try { //休眠1秒,保证deleteUserA先执行 Thread.sleep(1000); } catch (InterruptedException e) { e.printStackTrace(); } new Thread(() -> { int i = 1/0; userMapper.deleteUserB(); }).start(); }
七、事务传播属性设置错误
注意传播属性的设置,一般情况下,propagation属性无需配置。会使用默认配置,即:PROPAGATION_REQUIRED,有些propagation属性会导致事务不会触发,一定要注意:
- PROPAGATION_SUPPORTS: 如果存在事务,则进入事务;否则,以非事务方式运行。
- PROPAGATION_NOT_SUPPORTED: 如果存在事务,则挂起事务,并以非事务方式运行。
- PROPAGATION_NEVER: 以非事务形式运行,如果存在事务,则抛出异常。
总结
以上为个人经验,希望能给大家一个参考,也希望大家多多支持脚本之家。
相关文章
MyBatis批量插入的五种方式小结(MyBatis以集合方式批量新增)
本文主要介绍了MyBatis批量插入的五种方式小结(MyBatis以集合方式批量新增),文中通过示例代码介绍的非常详细,对大家的学习或者工作具有一定的参考学习价值,需要的朋友们下面随着小编来一起学习学习吧2023-01-01
最新评论