Spring Boot @Transactional事务不生效的10个常见原因分析 - 智猿学院-前后端，数据库，人工智能，云计算等领域前沿技术讲座

Spring Boot @Transactional 事务不生效的 10 个常见原因分析

大家好，今天我们来聊聊 Spring Boot 中 @Transactional 注解失效的常见原因。 @Transactional 是 Spring 框架中声明式事务管理的核心注解，它能够简化事务的管理，让开发者专注于业务逻辑。然而，在实际开发中，我们经常会遇到 @Transactional 注解不起作用的情况，导致数据一致性问题。这次讲座将深入分析 10 个导致 @Transactional 失效的常见原因，并提供相应的解决方案。

1. 数据库引擎不支持事务

首先，最基本但容易被忽略的是：你所使用的数据库引擎是否支持事务。例如， MySQL 的 MyISAM 引擎就不支持事务，而 InnoDB 引擎则支持。如果你的数据库表使用的是 MyISAM 引擎，即使你在代码中使用了 @Transactional 注解，事务也不会生效。

解决方案：

确保数据库引擎支持事务。对于 MySQL，将表引擎修改为 InnoDB。
```
ALTER TABLE your_table_name ENGINE=InnoDB;
```

2. 未配置事务管理器

Spring Boot 需要配置事务管理器才能正常工作。事务管理器负责管理事务的生命周期，包括事务的开始、提交和回滚。如果没有配置事务管理器，@Transactional 注解自然不会生效。

解决方案：

确保 Spring Boot 已经配置了事务管理器。通常，如果使用了 Spring Data JPA 或 JDBC，Spring Boot 会自动配置一个默认的事务管理器。但如果自定义了数据源，或者使用了多个数据源，就需要手动配置事务管理器。
```
@Configuration
@EnableTransactionManagement
public class TransactionConfig {

    @Bean
    public PlatformTransactionManager transactionManager(DataSource dataSource) {
        return new DataSourceTransactionManager(dataSource);
    }
}
```
其中，@EnableTransactionManagement 注解用于启用 Spring 的事务管理功能， PlatformTransactionManager 接口是 Spring 事务管理器的顶级接口。DataSourceTransactionManager 是基于 JDBC 的事务管理器，适用于使用 DataSource 进行数据访问的情况。

3. 方法不是 public 的

@Transactional 注解只能应用于 public 方法。这是因为 Spring 使用 AOP（面向切面编程）来实现事务管理，而 AOP 只能拦截 public 方法。如果将 @Transactional 注解应用于 private、protected 或 package-private 方法，事务将不会生效。

解决方案：

确保 @Transactional 注解应用于 public 方法。

@Service
public class UserService {

    @Autowired
    private UserRepository userRepository;

    @Transactional // 必须是 public
    public void createUser(User user) {
        userRepository.save(user);
    }
}

4. 同一个类中，方法内部调用

这是最常见的问题之一。当在同一个类中的一个方法内部调用另一个带有 @Transactional 注解的方法时，事务通常不会生效。这是因为 Spring 的 AOP 是基于代理实现的，而内部方法调用不会经过代理，因此事务增强逻辑不会被执行。

解决方案：

将带有 @Transactional 注解的方法移动到另一个类中，或者使用 ApplicationContext 获取当前类的代理对象，然后通过代理对象调用带有 @Transactional 注解的方法。

方法一：将方法移动到另一个类

@Service
public class UserService {

    @Autowired
    private UserRepository userRepository;

    @Autowired
    private UserHelper userHelper;

    @Transactional
    public void createUserWithHelper(User user) {
        userRepository.save(user);
        userHelper.updateUser(user); // 调用另一个类的事务方法
    }
}

@Service
public class UserHelper {

    @Autowired
    private UserRepository userRepository;

    @Transactional
    public void updateUser(User user) {
        user.setName("Updated Name");
        userRepository.save(user);
    }
}

方法二：使用 ApplicationContext 获取代理对象

@Service
public class UserService {

    @Autowired
    private UserRepository userRepository;

    @Autowired
    private ApplicationContext applicationContext;

    public void createUserWithInternalCall(User user) {
        userRepository.save(user);
        ((UserService) applicationContext.getBean("userService")).updateUser(user); // 通过代理对象调用
    }

    @Transactional
    public void updateUser(User user) {
        user.setName("Updated Name");
        userRepository.save(user);
    }
}

注意： 第二种方法依赖于 ApplicationContext，并且需要显式地获取代理对象，略显繁琐。推荐使用第一种方法，将事务方法分离到不同的类中。

5. 异常被捕获后没有重新抛出

如果在一个带有 @Transactional 注解的方法中，捕获了异常但没有重新抛出，Spring 默认会认为事务已经成功完成，从而提交事务。这会导致即使发生了错误，数据仍然会被保存到数据库中。

解决方案：

如果捕获了异常，务必重新抛出，以便 Spring 能够感知到异常并回滚事务。

@Service
public class UserService {

    @Autowired
    private UserRepository userRepository;

    @Transactional(rollbackFor = Exception.class) // 建议指定 rollbackFor
    public void createUser(User user) {
        try {
            userRepository.save(user);
            // 模拟异常
            if (user.getName().equals("Test")) {
                throw new RuntimeException("Simulated Exception");
            }
        } catch (Exception e) {
            System.err.println("Exception caught: " + e.getMessage());
            throw e; // 重新抛出异常，触发事务回滚
        }
    }
}

建议在 @Transactional 注解中指定 rollbackFor 属性，明确指定需要回滚的异常类型。这可以避免一些不必要的事务回滚。

6. 错误的传播行为（propagation）

@Transactional 注解的 propagation 属性定义了事务的传播行为，即当一个事务方法被另一个事务方法调用时，如何处理事务。如果传播行为配置不当，可能会导致事务不生效。

常见的传播行为：

传播行为	描述
`REQUIRED` (默认)	如果当前存在事务，则加入该事务；如果当前没有事务，则创建一个新的事务。
`REQUIRES_NEW`	总是创建一个新的事务。如果当前存在事务，则将当前事务挂起。
`SUPPORTS`	如果当前存在事务，则加入该事务；如果当前没有事务，则以非事务方式执行。
`NOT_SUPPORTED`	总是以非事务方式执行。如果当前存在事务，则将当前事务挂起。
`MANDATORY`	必须在一个已存在的事务中执行。如果当前没有事务，则抛出异常。
`NEVER`	必须以非事务方式执行。如果当前存在事务，则抛出异常。
`NESTED`	如果当前存在事务，则在嵌套事务中执行。如果当前没有事务，则创建一个新的事务。嵌套事务可以独立于外部事务进行提交或回滚。需要数据库支持嵌套事务（例如，JDBC 3.0 驱动）。

解决方案：

根据实际需求选择合适的传播行为。例如，如果希望一个方法总是创建一个新的事务，即使当前存在事务，可以使用 REQUIRES_NEW 传播行为。

@Service
public class UserService {

    @Autowired
    private UserRepository userRepository;

    @Transactional(propagation = Propagation.REQUIRED) // 默认行为
    public void createUser(User user) {
        userRepository.save(user);
        updateUser(user);
    }

    @Transactional(propagation = Propagation.REQUIRES_NEW) // 总是创建新事务
    public void updateUser(User user) {
        user.setName("Updated Name");
        userRepository.save(user);
    }
}

在这个例子中，createUser 方法使用默认的 REQUIRED 传播行为，而 updateUser 方法使用 REQUIRES_NEW 传播行为。即使 createUser 方法中发生了异常导致事务回滚，updateUser 方法的事务仍然会独立提交。

7. 事务超时

@Transactional 注解的 timeout 属性可以设置事务的超时时间，单位为秒。如果事务执行时间超过了超时时间，事务管理器会自动回滚事务。如果超时时间设置得过短，可能会导致事务在正常完成之前就被回滚。

解决方案：

根据实际需求设置合理的超时时间。如果事务涉及大量的数据库操作，或者需要执行一些耗时的操作，应该适当增加超时时间。

@Service
public class UserService {

    @Autowired
    private UserRepository userRepository;

    @Transactional(timeout = 30) // 设置超时时间为 30 秒
    public void createUser(User user) {
        userRepository.save(user);
        // 模拟耗时操作
        try {
            Thread.sleep(20000); // 睡眠 20 秒
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
    }
}

8. 只读事务

@Transactional 注解的 readOnly 属性可以设置为 true，表示这是一个只读事务。只读事务可以提高性能，因为数据库可以针对只读事务进行优化。但是，如果在只读事务中执行了写操作，可能会导致异常。

解决方案：

确保只读事务中只执行读操作。如果需要在只读事务中执行写操作，应该将 readOnly 属性设置为 false。

@Service
public class UserService {

    @Autowired
    private UserRepository userRepository;

    @Transactional(readOnly = true) // 只读事务
    public User getUserById(Long id) {
        return userRepository.findById(id).orElse(null);
    }

    @Transactional(readOnly = false) // 允许写操作
    public void updateUser(User user) {
        userRepository.save(user);
    }
}

9. 事务隔离级别

@Transactional 注解的 isolation 属性定义了事务的隔离级别。事务隔离级别越高，数据一致性越好，但并发性能越差。如果隔离级别设置不当，可能会导致数据一致性问题。

常见的隔离级别：

隔离级别	描述
`DEFAULT`	使用数据库的默认隔离级别。
`READ_UNCOMMITTED`	允许读取未提交的数据。这是最低的隔离级别，可能会导致脏读、不可重复读和幻读。
`READ_COMMITTED`	允许读取已提交的数据。可以防止脏读，但仍然可能发生不可重复读和幻读。
`REPEATABLE_READ`	确保在同一个事务中多次读取同一数据时，结果始终相同。可以防止脏读和不可重复读，但仍然可能发生幻读。
`SERIALIZABLE`	最高的隔离级别。强制事务串行执行，可以防止脏读、不可重复读和幻读。但是，并发性能最差。

解决方案：

根据实际需求选择合适的隔离级别。通常情况下，使用 READ_COMMITTED 或 REPEATABLE_READ 隔离级别即可满足大多数需求。

@Service
public class UserService {

    @Autowired
    private UserRepository userRepository;

    @Transactional(isolation = Isolation.READ_COMMITTED) // 设置隔离级别为 READ_COMMITTED
    public User getUserById(Long id) {
        return userRepository.findById(id).orElse(null);
    }

    @Transactional(isolation = Isolation.REPEATABLE_READ) // 设置隔离级别为 REPEATABLE_READ
    public void updateUser(User user) {
        userRepository.save(user);
    }
}

10. 使用了不支持事务的操作

某些操作可能不支持事务，例如，某些类型的消息队列操作。如果在事务中执行了这些操作，可能会导致事务无法正常工作。

解决方案：

避免在事务中执行不支持事务的操作。如果必须执行这些操作，可以考虑将它们移到事务之外，或者使用其他方式来保证数据一致性。例如，可以使用两阶段提交协议来保证消息队列操作和数据库操作的一致性。

表格总结常见原因及解决方案

原因	解决方案
数据库引擎不支持事务	确保数据库引擎支持事务 (例如 MySQL InnoDB)
未配置事务管理器	配置 PlatformTransactionManager
方法不是 public 的	确保 @Transactional 注解应用于 public 方法
同一个类中，方法内部调用	将方法移动到另一个类，或者使用 ApplicationContext 获取代理对象
异常被捕获后没有重新抛出	重新抛出异常，以便 Spring 能够感知到异常并回滚事务
错误的传播行为（propagation）	根据实际需求选择合适的传播行为
事务超时	设置合理的超时时间
只读事务	确保只读事务中只执行读操作
事务隔离级别	根据实际需求选择合适的隔离级别
使用了不支持事务的操作	避免在事务中执行不支持事务的操作，或使用其他方式保证数据一致性

快速回顾，保证事务正确运行

这次讲座我们深入剖析了 Spring Boot 中 @Transactional 注解失效的 10 个常见原因，并提供了相应的解决方案。记住检查数据库引擎，配置事务管理器，确保方法是 public 的，处理好内部方法调用和异常，选择合适的传播行为、超时时间、隔离级别，并避免使用不支持事务的操作。只有这样，才能保证 @Transactional 注解能够正确地发挥作用，确保数据的一致性和完整性。

Spring Boot @Transactional 事务不生效的 10 个常见原因分析

发表回复 取消回复

发表回复取消回复