Spring事务回滚失败怎么解决

从现在开始，努力学习吧！本文《Spring事务回滚失败原因及解决方法》主要讲解了等等相关知识点，我会在golang学习网中持续更新相关的系列文章，欢迎大家关注并积极留言建议。下面就先一起来看一下本篇正文内容吧，希望能帮到你！

本文深入探讨Spring框架中事务回滚失效的常见问题，特别是当多实体持久化操作未能保持原子性时。我们将分析Spring事务管理的核心机制，重点阐述事务传播行为、异常处理机制以及可能导致事务不回滚的陷阱，并提供确保事务原子性与可靠回滚的解决方案和最佳实践。

引言：Spring事务回滚失效的困境

在企业级应用开发中，数据操作的原子性至关重要。Spring框架通过其强大的事务管理功能，使得开发者能够轻松实现数据库操作的原子性、一致性、隔离性和持久性（ACID特性）。然而，在实际开发中，开发者有时会遇到事务未能按预期回滚的情况，即在一个事务性操作中，部分数据持久化成功，而另一部分因异常失败，但已成功的部分却未被回滚，导致数据不一致。

考虑以下场景，一个服务方法旨在同时持久化两个实体：

@Service
@Transactional(value = "db1TransactionManager")
public class ServiceImpl {

    @Autowired
    private Db1Repository db1Repository; // 假设已经注入

    @Override
    @Transactional // 默认PROPAGATION_REQUIRED
    public void insertOrUpdate(Entity1 entity1, Entity2 entity2) {
        db1Repository.insert(entity1, Entity1.class); // 第一次插入
        db1Repository.insert(entity2, Entity2.class); // 第二次插入，假设这里会失败
    }
}

@Repository(value = "db1Repository")
public class Db1RepositoryImpl implements Db1Repository {

    @PersistenceContext(unitName = "db1")
    private EntityManager em;

    @Override
    public <T> void insert(T entity, Class<T> tClass) {
        em.persist(entity);
        // em.flush(); // 通常不需要手动调用，事务提交时会自动flush
    }
}

当 entity2 被故意设置为 null 以触发持久化失败时，我们期望 entity1 的持久化也能被回滚。然而，实际结果却是 entity1 仍然被持久化到数据库中。这表明，尽管使用了 @Transactional 注解，但事务的原子性并未得到保证，两个插入操作未能被视为一个整体进行“同生共死”。

Spring事务管理核心机制

Spring的事务管理是基于AOP（面向切面编程）实现的。当一个方法被 @Transactional 注解标记时，Spring会为该方法创建一个代理对象。在方法执行前，代理会开启一个事务；方法执行成功后，事务会被提交；如果方法执行过程中抛出异常，事务则会被回滚。

核心组件包括：

• @Transactional 注解： 用于声明方法或类需要事务支持。可以配置事务传播行为、隔离级别、超时时间、只读属性以及回滚规则。
• PlatformTransactionManager： Spring事务抽象的核心接口，负责事务的开启、提交和回滚。不同的持久化技术（如JPA、JDBC、Hibernate）有各自的实现，例如 JpaTransactionManager。
• 持久化上下文（EntityManager 或 SessionFactory）： 负责管理实体生命周期和与数据库的交互。事务管理器通过它们来协调数据库操作。

深入理解事务传播行为

事务传播行为（Propagation Behavior）定义了客户端调用事务方法时，事务如何与当前上下文交互。这是理解事务回滚机制的关键。

PROPAGATION_REQUIRED：默认且推荐的原子性保证

PROPAGATION_REQUIRED 是 @Transactional 注解的默认传播行为。它的含义是：

• 如果当前存在事务，则加入该事务。
• 如果当前没有事务，则创建一个新的事务。

这意味着所有标记为 PROPAGATION_REQUIRED 的方法，如果被同一个外部事务调用，将共享同一个事务上下文。在这个共享的事务中，任何一个操作失败并抛出异常，都将导致整个事务回滚，从而保证操作的原子性——要么全部成功，要么全部失败。在上述示例中，insertOrUpdate 方法以及其内部调用的 db1Repository.insert 方法，如果都处于 PROPAGATION_REQUIRED 模式下，并且从外部调用 insertOrUpdate 时没有现有事务，Spring会为 insertOrUpdate 创建一个新事务。理论上，内部的两个 insert 操作应该都在这个事务中。

PROPAGATION_NESTED：内嵌事务（非本例直接原因，但结果类似）

PROPAGATION_NESTED 会在一个现有事务的内部创建一个“内嵌事务”（或称作保存点）。内嵌事务可以独立于外部事务进行回滚，但其提交却依赖于外部事务的提交。如果外部事务回滚，所有内嵌事务也会回滚。这种行为虽然在某些场景下有用，但与我们期望的“同生共死”的原子性不同。

在我们的例子中，虽然没有显式使用 PROPAGATION_NESTED，但当 entity1 被持久化而 entity2 失败时，其结果看起来就好像 entity1 的操作与 entity2 的操作不在同一个原子事务中，或者说 entity1 的操作已经“提交”了，而 entity2 的操作失败。这暗示了在事务边界或异常处理上存在问题。

关键分析：为什么事务没有原子性回滚？

当 PROPAGATION_REQUIRED 未能按预期工作时，通常有以下几个主要原因：

1. 异常类型与回滚策略

Spring默认只对运行时异常（RuntimeException 及其子类）和 Error 进行事务回滚。对于受检异常（Checked Exception，如 IOException、SQLException 等），Spring默认不会触发回滚。

在示例中，如果 entity2 为 null 导致的是一个受检异常（例如，某个自定义验证器抛出受检异常），并且没有被转换为运行时异常，那么事务就不会回滚。

解决方案：

• 确保业务逻辑抛出的是 RuntimeException 或其子类。
• 如果必须抛出受检异常，可以通过 @Transactional 的 rollbackFor 属性明确指定需要回滚的异常类型：

  @Transactional(rollbackFor = MyCheckedException.class)
  public void insertOrUpdate(...) throws MyCheckedException {
      // ...
  }

2. 异常捕获与吞噬

这是最常见的问题之一。如果在事务方法内部或其调用的方法内部，异常被 try-catch 块捕获，但未再次抛出（或只抛出了一个非运行时异常），Spring事务管理器将无法感知到异常的发生。在这种情况下，方法会正常结束，事务管理器会认为操作成功，从而提交事务，导致数据不一致。

// 错误示例：异常被吞噬
@Transactional
public void insertOrUpdate(Entity1 entity1, Entity2 entity2) {
    db1Repository.insert(entity1, Entity1.class);
    try {
        db1Repository.insert(entity2, Entity2.class); // 假设这里抛出异常
    } catch (Exception e) {
        // 异常被捕获，但没有重新抛出，事务不会回滚
        System.err.println("Error inserting entity2: " + e.getMessage());
        // 可以记录日志，但不能吞噬异常
    }
}

解决方案：

• 不要在事务方法内部捕获并吞噬应该触发回滚的异常。
• 如果确实需要捕获异常进行特定处理（如日志记录），处理完毕后必须重新抛出 RuntimeException 或使用 TransactionAspectSupport.currentTransactionStatus().setRollbackOnly() 显式标记事务为回滚状态。

// 正确示例：重新抛出异常
@Transactional
public void insertOrUpdate(Entity1 entity1, Entity2 entity2) {
    db1Repository.insert(entity1, Entity1.class);
    try {
        db1Repository.insert(entity2, Entity2.class);
    } catch (Exception e) {
        // 记录日志后，将异常包装为运行时异常重新抛出
        throw new RuntimeException("Failed to insert entity2, rolling back transaction.", e);
    }
}

// 或者，如果不想改变异常类型，但要强制回滚
import org.springframework.transaction.interceptor.TransactionAspectSupport;

@Transactional
public void insertOrUpdate(Entity1 entity1, Entity2 entity2) {
    db1Repository.insert(entity1, Entity1.class);
    try {
        db1Repository.insert(entity2, Entity2.class);
    } catch (Exception e) {
        // 记录日志
        System.err.println("Error inserting entity2: " + e.getMessage());
        // 标记当前事务为回滚
        TransactionAspectSupport.currentTransactionStatus().setRollbackOnly();
        // 可以选择继续抛出原异常，或者让方法正常结束（但事务已被标记回滚）
        throw e; // 推荐重新抛出，让调用方感知到失败
    }
}

3. 事务代理失效（自调用问题）

当同一个类中的一个非事务方法调用另一个事务方法时，或者一个事务方法内部调用同一个类的另一个事务方法时，@Transactional 注解可能不会生效。这是因为Spring的AOP代理机制是通过代理对象来拦截方法调用的。如果方法是内部调用，则直接通过 this 引用调用，绕过了代理对象。

@Service
public class ServiceImpl {

    @Transactional // 这个事务不会生效，因为是内部调用
    public void transactionalMethod() {
        // ...
    }

    public void nonTransactionalMethod() {
        this.transactionalMethod(); // 直接调用，绕过代理
    }
}

解决方案：

• 将需要事务支持的方法放在独立的Spring Bean中。
• 通过 ApplicationContext 获取当前Bean的代理对象进行调用（不推荐，代码复杂）。
• 在同一个类中，如果事务方法需要被另一个方法调用，确保外部调用方是事务的入口，或者被调用的事务方法有独立的事务语义。

在我们的原始示例中，insertOrUpdate 方法是外部调用的入口，所以这个问题不直接适用，但它是Spring事务管理中一个常见的陷阱。

4. em.flush() 操作的影响

EntityManager.persist() 方法只是将实体放入持久化上下文（一级缓存），并不会立即写入数据库。实际的数据库写入操作通常发生在 EntityManager.flush() 或事务提交时。如果 entity1 在事务提交前因某种原因被 flush（例如，执行了某些查询操作可能隐式触发 flush，或者手动调用了 em.flush()），而 entity2 的错误发生在 flush 之后，并且异常被吞噬，则 entity1 可能已经写入数据库。

解决方案：

• 避免在事务方法内部不必要地手动调用 em.flush()。
• 如果必须调用，要清楚其可能带来的副作用，并确保异常处理得当。
• 在 PROPAGATION_REQUIRED 模式下，如果异常正确传播，即使 entity1 已经被 flush 到数据库，事务回滚也会撤销这些操作。

解决方案与最佳实践

要确保Spring事务的原子性和可靠回滚，请遵循以下最佳实践：

1. 明确事务边界： 将所有需要原子性操作的代码封装在一个 @Transactional 方法中，并确保该方法是外部调用的入口。
2. 避免异常吞噬： 永远不要在事务方法内部或其调用的方法内部，捕获并吞噬应该触发回滚的异常。如果必须捕获，请务必重新抛出 RuntimeException 或使用 TransactionAspectSupport.currentTransactionStatus().setRollbackOnly() 标记事务为回滚。
3. 理解异常类型： 牢记Spring默认只回滚运行时异常。对于受检异常，要么将其转换为运行时异常，要么通过 @Transactional(rollbackFor = MyCheckedException.class) 明确指定回滚。
4. 配置正确的事务管理器： 确保 PlatformTransactionManager 配置正确，并与数据源或 EntityManagerFactory 正确关联。如果使用多数据源，请确保为每个数据源配置了独立的事务管理器，并在 @Transactional 注解中通过 value 属性指定使用哪个事务管理器。
5. 合理设计业务逻辑： 将复杂的业务逻辑分解为更小、更内聚的方法。如果某些操作不需要事务支持，则不要将其标记为 @Transactional，或者使用 PROPAGATION_NOT_SUPPORTED。
6. 使用数据库约束： 除了应用层的验证，数据库层面的约束（如非空约束、唯一约束、外键约束）也是保证数据完整性的最后一道防线。当 entity2 为 null 时，如果对应的数据库列有 NOT NULL 约束，数据库会抛出异常，这通常是 RuntimeException 的子类，能够被Spring事务管理器捕获并触发回滚。

示例代码（修正版）

以下是基于原始问题的修正版本，重点在于确保异常的正确传播：

@Service
@Transactional(value = "db1TransactionManager") // 可以在类级别定义默认

终于介绍完啦！小伙伴们，这篇关于《Spring事务回滚失败怎么解决》的介绍应该让你收获多多了吧！欢迎大家收藏或分享给更多需要学习的朋友吧~golang学习网公众号也会发布文章相关知识，快来关注吧！