SpringBoot中事务失效的六个原因

文章详细列举了SpringBoot中事务可能失效的六个原因,包括事务方法需为public、非事务方法调用事务方法、异常处理不当、事务异常类型错误、事务传播行为设置错误以及类未被Spring管理。这些问题可能导致事务无法正常回滚,影响数据库操作的一致性。解决方案包括正确配置事务传播行为、处理异常和确保类被Spring管理。
SpringBoot中事务失效的原因🚩

常见的事务失效原因包括如下六个:

1. 事务方法非public修饰

由于Spring的事务是基于AOP的方式结合动态代理来实现的。因此事务方法一定要是public的,这样才能便于被Spring做事务的代理和增强。

而且,在Spring内部也会有一个 org.springframework.transaction.interceptor.AbstractFallbackTransactionAttributeSource类,去检查事务方法的修饰符:

@Nullable
 protected TransactionAttribute computeTransactionAttribute(
  Method method, @Nullable Class<?> targetClass) {
   // Don't allow non-public methods, as configured.
   if (allowPublicMethodsOnly() && 
  !Modifier.isPublic(method.getModifiers())) {
      return null;
   }

    // ... 略

   return null;
 }
2. 非事务方法调用事务方法
@Service
public class OrderService {
    
    public void createOrder(){
        // ... 准备订单数据
        
        // 生成订单并扣减库存
        insertOrderAndReduceStock();
    }
    
    @Transactional
    public void insertOrderAndReduceStock(){
        // 生成订单
        insertOrder();
        // 扣减库存
        reduceStock();
    }
}

可以看到,insertOrderAndReduceStock方法是一个事务方法,肯定会被Spring事务管理。Spring会给OrderService类生成一个动态代理对象,对insertOrderAndReduceStock方法做增加,实现事务效果。

但是现在createOrder方法是一个非事务方法,在其中调用了insertOrderAndReduceStock方法,这个调用其实隐含了一个this.的前缀。也就是说,这里相当于是直接调用原始的OrderService中的普通方法,而非被Spring代理对象的代理方法。那事务肯定就失效了!

3. 事务方法的异常被捕获了

异常被捕获了但是没有往外抛异常,所以事务没有发现方法中出现错误,所以也就没有回滚

 @Transactional
    public void createOrder(){
        // ... 准备订单数据
        // 生成订单
        insertOrder();
        // 扣减库存
        reduceStock();
    }

    private void reduceStock() {
        try {
            // ...扣库存
        } catch (Exception e) {
            // 处理异常
        }
    }

在这段代码中,reduceStock方法内部直接捕获了Exception类型的异常,也就是说方法执行过程中即便出现了异常也不会向外抛出。

而Spring的事务管理就是要感知业务方法的异常,当捕获到异常后才会回滚事务。

现在事务被捕获,就会导致Spring无法感知事务异常,自然不会回滚,事务就失效了。

4. 事务异常类型不对
@Transactional(rollbackFor = RuntimeException.class)
public void createOrder() throws IOException {
    // ... 准备订单数据

    // 生成订单
    insertOrder();
    // 扣减库存
    reduceStock();

    throw new IOException();
}

Spring的事务管理默认感知的异常类型是RuntimeException,当事务方法内部抛出了一个IOException时,不会被Spring捕获,因此就不会触发事务回滚,事务就失效了。

因此,当我们的业务中会抛出RuntimeException以外的异常时,应该通过@Transactional注解中的rollbackFor属性来指定异常类型:

@Transactional(rollbackFor = Exception.class)
5.事务传播行为不对
    @Transactional
    public void createOrder(){
        // 生成订单
        insertOrder();
        // 扣减库存
        reduceStock();
        throw new RuntimeException("业务异常");
    }

	@Transactional  // 默认的是如果当前没有事务,自己创建事务,如果有事务则加入
    public void insertOrder() {
    
    }
	// 不管当前方法所在方法有没有都开启一个事务
    @Transactional(propagation = Propagation.REQUIRES_NEW)
    public void reduceStock() {
        
    }

在示例代码中,事务的入口是createOrder()方法,会开启一个事务,可以成为外部事务。在createOrder()方法内部又调用了insertOrder()方法和reduceStock()方法。这两个都是事务方法。

不过,reduceStock()方法的事务传播行为是REQUIRES_NEW,这会导致在进入reduceStock()方法时会创建一个新的事务,可以成为子事务。insertOrder()则是默认,因此会与createOrder()合并事务。

因此,当createOrder方法最后抛出异常时,只会导致insertOrder方法回滚,而不会导致reduceStock方法回滚,因为reduceStock是一个独立事务。

所以,一定要慎用传播行为,注意外部事务与内部事务之间的关系。

6.没有被Spring管理

即当前类没有被SpringBoot扫描

第二种事务失效的解决方案:

上面的问题在于非事务方法中调用事务方法其中隐含了一个this.的前缀, 虽然当前方法的事务也被代理类生成了,但是因为默认关键字的原因,调用的还是原来的是没有事务的方法.

所以我们现在要做的就是要找到被代理之后的类,然后再在方法中调用该方法

1)引入AspectJ依赖:
<!--aspecj-->
<dependency>
    <groupId>org.aspectj</groupId>
    <artifactId>aspectjweaver</artifactId>
	<version>1.9.7</version>
</dependency>
2)暴露代理对象

在启动类上添加注解,暴露代理对象:

3)使用代理对象

通过AopContext拿到当前类的代理对象,然后调用对应方法

// 返回值是Object
IUserCouponService userCouponService = (IUserCouponService) AopContext.currentProxy();
userCouponService.insertCouponAndCheck(userId, coupon, null);

(补充🌴 )StringBoot中事务相关的接口

在Spring中有两个和事务相关的接口

  1. PlatformTransactionManager 平台事务管理接口

    作用; 对于不同的数据源采用不同的管理平台, 常用的实现类如下

    • DataSourceTransactionManager:使用JDBC或MyBatis进行事务管理。适用于DataSource数据源。

    • HibernateTransactionManager:使用Hibernate进行事务管理。适用于Hibernate持久层框架。

  2. TransactionDefinition 事务定义接口

TransactionDefinition 接口中定义了事务的描述相关的三类常量:

  1. 事务隔离级别
  2. 事务传播行为
  3. 事务默认超时时限

1. 事务隔离级别
  1. DEFAULT : 采用DB默认的事务隔离级别.mysql中默认的是 REPEATABLE_READ (repeatable_read)

  2. READ_UNCOMMITTED: 读未提交 未解决任何并发问题

  3. READ_COMMITTED: 读已提交 解决了脏读,存在不可重复读和幻读

  4. REPETABLE_READ : 可重复读,解决了脏读,不可重复读,存在幻读

  5. SERIALIZABLE :串行化.不存在并发问题

那么什么是脏读, 幻读和 不可重复读呢?

脏读(dirty read): 当一个事务读取另一个事务尚未提交的修改时,产生脏读

不可重复读(nonrepeatable read):同一查询在同一事务中多次进行,由于其他提交事务所做的修改或删除,每次返回不同的结果集,此时发生不可重复读

幻读(phantom read):同一查询在同一事务中多次进行,由于其他提交事务所做的插入操作,每次返回不同的结果集,此时发生幻读

2. 事务的传播行为
  1. 定义了七个事务的传播行为:都是以 PROPAGATION_开头 propagation(常用三个)

事务传播行为是指,处于不同事务中的方法在相互调用时,执行期间事务的维护情况

  1. propagation_required (spring默认的传播行为)

  2. propagation_requires_new

  3. propagation_supports

propagation_required :

说明:指定的方法必须在事务内执行。若当前存在事务,就加入到当前事务中;若当前没有事务,则创建一个新事务。这种传播行为是最常见的选择,也是 Spring 默认的事务传播行为。 

演示说明:

**如该传播行为加在doOther()**方法上。若 doSome()方法在调用 doOther()方法时就是在事务内运行的,则 doOther()方法的执行也加入到该事务内执行。若 doSome()方法在调用 doOther()方法时没有在事务内执行,则 doOther()方法会创建一个事务,并在其中执行。

propagation_requires_new:

说明:总是新建一个事务,如当前存在事务,就将当前事务挂起,直到新事务执行完毕

propagation_supports:

说明:指定的方法支持当前事务,但若当前没有事务,也可以以非事务方法执行

3. 事务超时时限

该值一般就是用默认值

### Spring Boot 与 Apache Doris 集成时事务失效原因及解决方案 在使用 Spring Boot 和 Apache Doris 的场景下,如果遇到事务管理失效的问题,通常是因为 Doris 数据库本身的设计特点以及其与其他组件交互的方式所致。以下是可能原因及其对应的解决方案: #### 1. **Doris 不支持分布式事务** Doris 是一款专注于 OLAP 场景的高性能数据库,在设计上并未完全实现传统关系型数据库中的 ACID 特性[^1]。具体来说,Doris 更倾向于优化批量写入和实时查询性能,而对跨多个操作的一致性和隔离性支持有限。 因此,当尝试通过 Spring Boot 中的标准 `@Transactional` 注解来控制事务时,可能会发现该功能无法正常工作。这是因为 Doris 并未提供完整的 XA 协议或其他分布式事务机制的支持[^2]。 ```java @Service public class MyService { @Autowired private MyRepository myRepository; @Transactional // 这里可能不会生效 public void saveData() { try { myRepository.saveFirstRecord(); throw new RuntimeException("Simulated error"); } finally { myRepository.saveSecondRecord(); // 可能会被执行 } } } ``` 上述代码片段展示了即使抛出了异常,第二个记录仍有可能被保存的情况。 --- #### 2. **JDBC 驱动兼容性问题** 目前,Doris 提供了自己的 JDBC 驱动程序用于连接客户端应用。然而,某些版本可能存在与 Spring Data 或 Hibernate 等框架集成上的局限性。例如,默认情况下,驱动可能不支持回滚 (ROLLBACK) 操作或者未能正确识别事务边界[^3]。 针对此情况,可以通过调整配置文件或升级至最新稳定版驱动解决问题: ```properties spring.datasource.driver-class-name=com.mysql.cj.jdbc.Driver spring.datasource.url=jdbc:mysql://<your-doris-host>:8030/<database>?useUnicode=true&characterEncoding=utf8&serverTimezone=UTC spring.datasource.username=<username> spring.datasource.password=<password> # 显式指定事务管理模式 spring.jpa.properties.hibernate.connection.provider_disables_autocommit=true ``` 注意这里虽然指定了 MySQL 的驱动类名 (`com.mysql.cj.jdbc.Driver`) ,但实际上它是用来适配 Doris SQL 接口的一种方式。 --- #### 3. **手动处理事务逻辑** 鉴于以上限制条件,一种可行的办法就是放弃依赖声明式的事务控制方法 (@Transactional),转而在业务层面上显式调用 begin/commit/rollback 方法来自定义行为: ```java @Autowired private DataSourceTransactionManager transactionManager; @Autowired private PlatformTransactionDefinition definition; public void customSaveLogic(){ DefaultTransactionStatus status = null; TransactionDefinition def = new DefaultTransactionDefinition(); status = transactionManager.getTransaction(def); try{ repository.insertBatchRecords(); transactionManager.commit(status); }catch(Exception e){ if(null !=status && !status.isCompleted()){ transactionManager.rollback(status); } log.error("Error during saving records",e); } } ``` 尽管这种方法增加了复杂度,但它能够更好地适应像 Doris 这样的特殊存储引擎需求。 --- #### 4. **重新评估数据模型选择的影响** 最后值得注意的是,之前提到的数据建模决策也可能间接影响到事务表现形式。比如选择了 Aggregate 类型作为默认结构却很少实际利用其中预设好的 rollup 功能,则意味着每次更新都需要额外维护那些无意义的冗余列值。这不仅浪费资源还可能导致潜在一致性风险加剧。 为此建议定期审查现有架构布局并适时作出改进措施以满足不断变化的应用诉求。 --- ### 总结 由于 Apache Doris 对于经典 RDBMS 所具备的一些特性有所取舍,所以在将其融入基于 Spring Boot 构建的企业级应用程序之时需格外留意两者间差异之处。对于当前所面临之难题——即事务不起作用现象,可考虑采用更灵活的手工操控手段加以应对;与此同时也要持续关注官方文档动态以便及时采纳最佳实践指导方针。
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

yfs1024

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

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

余额充值