5154

内部调用与传播行为错误

这类错误更具迷惑性,通常发生在代码逻辑层面，与AOP的实现机制和事务的传播特性紧密相关。

事务方法自调用失效

在一个Service类中,一个没有事务注解的方法调用了同一个类中另一个带有@Transactional注解的方法，事务不会生效。

@Service
public class OrderServiceImpl implements OrderService {
    public void createOrder() {
        // ...业务逻辑
        updateStock(); // 自调用，事务失效
    }
    @Transactional
    public void updateStock() {
        // ...更新库存
    }
}

• 原因： 这是因为createOrder()方法内部调用updateStock()时，是通过this引用直接调用的，而不是通过Spring创建的代理对象调用，AOP的事务切面无法拦截到这次调用，事务也就不会开启。
  • 解决方案：
    1. 最佳实践： 将需要事务的方法（如updateStock）提取到另一个Service中，然后注入并调用。
    2. 变通方案： 在类中注入自身代理，通过代理对象调用，需要先在启动类上添加@EnableAspectJAutoProxy(exposeProxy = true)，然后在方法内通过((OrderService) AopContext.currentProxy()).updateStock()调用。

异常处理与回滚规则错误

事务的核心功能之一是异常回滚,而错误的异常处理是导致数据不一致的常见“元凶”。

异常被“吃掉”导致不回滚

在事务方法内部,如果将异常捕获并“吞掉”（即try-catch后不抛出），事务管理器将感知不到异常的发生，从而执行提交操作而非回滚。

@Transactional
public void payment() {
    try {
        // ...扣款、增加积分等操作
        // throw new RuntimeException("模拟异常");
    } catch (Exception e) {
        // 异常被捕获，没有重新抛出，事务不会回滚
        log.error("支付失败", e);
    }
}

• 原因： Spring的事务回滚是基于异常触发的，如果异常没有从事务方法中抛出，Spring认为方法正常执行完毕。
  • 解决方案：
    1. 在catch块中重新抛出异常：throw new RuntimeException(e);。
    2. 手动设置事务回滚：TransactionAspectSupport.currentTransactionStatus().setRollbackOnly();。

默认回滚规则不匹配

Spring事务默认只对RuntimeException（运行时异常）和Error类型进行回滚，对于受检异常，如IOException、SQLException等，默认不回滚。

• 原因： 这是Spring框架的设计哲学，认为受检异常通常是业务逻辑可预知、可处理的，不应强制回滚。
  • 解决方案： 使用@Transactional注解的rollbackFor或noRollbackFor属性来明确指定回滚的异常类型，希望所有异常都回滚：@Transactional(rollbackFor = Exception.class)。

为了更直观地小编总结,下表列出了常见问题与对策：

相关问答FAQs

Q1: @Transactional注解应该加在接口上还是实现类上？

A1: 这是一个经典问题，虽然加在接口和实现类上在多数情况下都能工作，但最佳实践是将其放在实现类上，原因在于：事务是具体实现层面的细节，不应该暴露在接口定义中，接口定义的是业务契约，而如何管理事务（如传播行为、隔离级别、回滚规则）是内部实现策略，将注解放在实现类上，更符合面向接口编程和关注点分离的原则，当Spring使用CGLIB（基于类的代理）时，注解放在接口上可能会失效，而放在实现类上则始终有效。

Q2: Spring事务和JTA（Java Transaction API）事务有什么区别？

A2: 两者的核心区别在于事务的边界和范围。

• Spring事务（特指其DataSourceTransactionManager等本地事务管理器）通常管理的是单资源事务，即针对一个数据库的连接，它轻量级、高效，适用于绝大多数单体应用或微服务中单一数据源的场景。
• JTA（Java Transaction API） 则用于管理分布式事务或全局事务，它可以协调跨多个资源的事务，例如同时更新两个不同的数据库，或者一个数据库和一个消息队列（如JMS），JTA需要一个应用服务器（如JBoss, WebSphere）或一个独立的JTA实现（如Atomikos, Narayana）作为事务协调器。

Spring本地事务是“局部”的，而JTA是“全局”的，Spring也提供了对JTA的支持（通过JtaTransactionManager），可以在需要分布式事务能力时整合JTA，但其配置和使用复杂度远高于本地事务，在非必要场景下，应优先使用Spring的本地事务。