spring 事务失效的几种场景

一、背景

        在 springBoot 开发过程中，我们一般都是在业务方法上添加 @Transactional 注解来让 spring 替我们管理事务，但在某些特定的场景下，添加完注解之后，事务是不生效的，接下来详细介绍下。

二、方法不是 public

2.1 场景描述

        当添加 @Transactional 注解的方法不是 public 类型的，事务会失效。如下代码：

@Transactional
private void someTransactionalMethod() {
    // 业务逻辑
}

2.2 原因分析

        在 Spring 中，只有 public 方法才能被 AOP 代理处理，因此如果 @Transactional 注解的方法不是 public 的，事务管理将失效。

2.3 解决方案

        确保 @Transactional 注解的方法是 public。如下：

@Transactional
public void someTransactionalMethod() {
    // 业务逻辑
}

三、方法内部调用

3.1 场景描述

        当一个类内部的方法调用另一个标注了 @Transactional 的方法时，事务管理将失效。如下代码：

@Service
public class MyServiceImpl {

    public void outerMethod() {
        publicMethod();
    }	
	@Transactional
    public void publicMethod() {
        // 业务逻辑
    }
}

3.2 原因分析

        这是因为内部方法方法的调用没有经过代理类，即在 outerMethod() 方法里面调用的 publicMethod() 方法是 MyServiceImpl 对象调用的，并不是经过 spring 代理类来调用的，所以事务会失效。

3.3 解决方案

        解决方案就是通过代理对象方法调用，使用 AOP 代理进行事务管理，如下代码：

@Service
public class MyServiceImpl {

    public void outerMethod() {
       // 通过代理对象调用 publicMethod
		((MyServiceImpl) AopContext.currentProxy()).publicMethod();
    }	
	@Transactional
    public void publicMethod() {
        // 业务逻辑
    }
}

四、未被 spring 管理

4.1 场景描述

        当一个类没有被 spring 管理时，事务不会生效，如下代码：

​public class MyServiceImpl {

    @Transactional
    public void someTransactionalMethod() {
        // 业务逻辑
    }
}

4.2 原因分析

        只有在 Spring 容器中管理的 bean，才能被 AOP 代理。如果 @Transactional 注解的方法所在的类没有被 Spring 管理，事务管理将失效。

4.3 解决方案

        确保类被 Spring 容器管理，如通过 @Service，@Component 等注解。

@Service​
public class MyServiceImpl {

    @Transactional
    public void someTransactionalMethod() {
        // 业务逻辑
    }
}

五、方法用 final 或 static 修饰

5.1 场景描述

        有时候，某个方法不想被子类重写，这时可以将该方法定义成 final 的。普通方法这样定义是没问题的，但如果将事务方法定义成 final，那么事务将会失效。

@Service
public class UserService {
 
	@Transactional
	public final void add(UserModel userModel){
		saveData(userModel);
		updateData(userModel);
	}
}

5.2 原因分析

        spring 事务底层使用了 aop，也就是通过 jdk 动态代理或者 cglib，帮我们生成了代理类，在代理类中实现的事务功能。但如果某个方法用 final 修饰了，那么在它的代理类中，就无法重写该方法，而添加事务功能。

        注意：如果某个方法是 static 的，同样无法通过动态代理，变成事务方法。

5.3 解决方案

        不使用 final 或者 static 修饰方法，如下：

@Service
public class UserService {
 
	@Transactional
	public void add(UserModel userModel){
		saveData(userModel);
		updateData(userModel);
	}
}

六、配置不当

6.1 场景描述

        @Transactional 注解的一些配置属性，可能会影响事务的行为，如下代码：

@Transactional(readOnly = true) 
public void someTransactionalMethod() {
    // 业务逻辑
}

6.2 原因分析

        配置了 readOnly=true 属性，那么执行增删改操作时就会报错。因为这个属性指定了此方法只能进行读操作。

6.3 解决方案

        检查配置的具体含义，确保其适当应用。

@Transactional(readOnly = false) 
public void someTransactionalMethod() {
    // 业务逻辑
}

七、多线程调用

7.1 场景描述

        spring 事务在多线程场景下，会有问题，如下代码

@Service
public class UserService {
 
	@Autowired
	private UserMapper userMapper;
	@Autowired
	private RoleService roleService;
 
	@Transactional
	public void add(UserModel userModel) throws Exception {
		userMapper.insertUser(userModel);
		new Thread(() -> {
			roleService.doOtherThing();
		}).start();
	}
}
 
@Service
public class RoleService {
 
	@Transactional
	public void doOtherThing() {
		System.out.println("保存role表数据");
	}
}

7.2 原因分析

        从上面的例子中，我们可以看到事务方法 add 中，调用了事务方法 doOtherThing，但是事务方法 doOtherThing 是在另外一个线程中调用的。

        这样会导致两个方法不在同一个线程中，获取到的数据库连接不一样，从而是两个不同的事务。如果将来 doOtherThing 方法中抛了异常，add 方法也回滚是不可能的。

        如果看过 spring 事务源码的朋友，可能会知道 spring 的事务是通过数据库连接来实现的。当前线程中保存了一个 map，key 是数据源，value 是数据库连接。

        我们说的同一个事务，其实是指同一个数据库连接，只有拥有同一个数据库连接才能同时提交和回滚。如果在不同的线程，拿到的数据库连接肯定是不一样的，所以是不同的事务。

7.3 解决方案

        避免在多线程中使用 @Transactional，或者手动管理线程间的事务。

@Service
public class MyService {

    @Transactional
    public void someTransactionalMethod() {
        ExecutorService executorService = Executors.newSingleThreadExecutor();
        executorService.submit(() -> {
            // 手动管理事务
            TransactionStatus status = transactionManager.getTransaction(new DefaultTransactionDefinition());
            try {
                // 业务逻辑
                transactionManager.commit(status);
            } catch (Exception e) {
                transactionManager.rollback(status);
                throw e;
            }
        });
    }
}

八、错误的传播特性

8.1 场景描述

        如果我们在手动设置 propagation 参数的时候，把传播特性设置错了，事务可能就不会生效，如下代码：

@Service
public class UserService {
 
	@Transactional(propagation = Propagation.NEVER)
	public void add(UserModel userModel) {
		saveData(userModel);
		updateData(userModel);
	}
}

8.2 原因分析

        propagation 参数的作用是指定事务的传播特性，spring 目前支持 7 种传播特性：

        EQUIRED：如果当前上下文中存在事务，则加入该事务，如果不存在事务，则创建一个事务，这是默认的传播属性值。

       SUPPORTS：如果当前上下文中存在事务，则支持事务加入事务，如果不存在事务，则使用非事务的方式执行。

        MANDATORY：当前上下文中必须存在事务，否则抛出异常。

        REQUIRES_NEW：每次都会新建一个事务，并且同时将上下文中的事务挂起，执行当前新建事务完成以后，上下文事务恢复再执行。

        NOT_SUPPORTED：如果当前上下文中存在事务，则挂起当前事务，然后新的方法在没有事务的环境中执行。

        NEVER：如果当前上下文中存在事务，则抛出异常，否则在无事务环境上执行代码。

        NESTED：如果当前上下文中存在事务，则嵌套事务执行，如果不存在事务，则新建事务。

        我们可以看到 add 方法的事务传播特性定义成了 Propagation.NEVER，这种类型的传播特性不支持事务，如果有事务则会抛异常。

8.3 解决方案

        目前只有这三种传播特性才会创建新事务：REQUIRED，REQUIRES_NEW，NESTED。

@Service
public class UserService {
 
	@Transactional(propagation = Propagation.REQUIRED)
	public void add(UserModel userModel) {
		saveData(userModel);
		updateData(userModel);
	}
}

九、自己吞了异常

8.1 场景描述

        开发者在代码中手动 try...catch 了异常，事务不会生效，如下代码：

@Slf4j
@Service
public class UserService {
	
	@Transactional
	public void add(UserModel userModel) {
		try {
			saveData(userModel);
			updateData(userModel);
		} catch (Exception e) {
			log.error(e.getMessage(), e);
		}
	}
}

8.2 原因分析

        这种情况下 spring 事务当然不会回滚，因为开发者自己捕获了异常，又没有手动抛出，换句话说就是把异常吞掉了。

8.3 解决方案

        如果想要 spring 事务能够正常回滚，必须抛出它能够处理的异常。如果没有抛异常，则 spring 认为程序是正常的。如下代码：

@Slf4j
@Service
public class UserService {
	
	@Transactional
	public void add(UserModel userModel)throws Exception {
		saveData(userModel);
		updateData(userModel);
	}
}

十、手动抛了别的异常

8.1 场景描述

        即使开发者没有手动捕获异常，但如果抛的异常不正确，spring 事务也不会回滚。如下代码：

@Slf4j
@Service
public class UserService {
	
	@Transactional
	public void add(UserModel userModel) throws Exception {
		try {
			 saveData(userModel);
			 updateData(userModel);
		} catch (Exception e) {
			log.error(e.getMessage(), e);
			throw new Exception(e);
		}
	}
}

8.2 原因分析

        上面的这种情况，开发人员自己捕获了异常，又手动抛出了异常：Exception，事务同样不会回滚。

        因为 spring 事务，默认情况下只会回滚 RuntimeException（运行时异常）和 Error（错误），对于普通的 Exception（非运行时异常），它不会回滚。

8.3 解决方案

        别采取这种写法。

十一、自定义了回滚异常

11.1 场景描述

        在使用 @Transactional 注解声明事务时，有时我们想自定义回滚的异常，spring 也是支持的。可以通过设置 rollbackFor 参数，来完成这个功能。但如果这个参数的值设置错了，就会引出一些莫名其妙的问题，如下代码：

@Slf4j
@Service
public class UserService {
	
	@Transactional(rollbackFor = BusinessException.class)
	public void add(UserModel userModel) throws Exception {
	   saveData(userModel);
	   updateData(userModel);
	}
}

11.2 原因分析

        如果在执行上面这段代码，保存和更新数据时，程序报错了，抛了 SqlException、DuplicateKeyException 等异常。而 BusinessException 是我们自定义的异常，报错的异常不属于 BusinessException，所以事务也不会回滚。

        即使 rollbackFor 有默认值，但阿里巴巴开发者规范中，还是要求开发者重新指定该参数。

11.3 解决方案

        如果使用默认值，一旦程序抛出了 Exception，事务不会回滚，这会出现很大的 bug。所以，建议一般情况下，将该参数设置成：Exception 或 Throwable。