Javaweb之SpringBootWeb案例之事务进阶的详细解析

1.3 事务进阶

前面我们通过spring事务管理注解@Transactional已经控制了业务层方法的事务。接下来我们要来详细的介绍一下@Transactional事务管理注解的使用细节。我们这里主要介绍@Transactional注解当中的两个常见的属性：

1. 异常回滚的属性：rollbackFor

2. 事务传播行为：propagation

我们先来学习下rollbackFor属性。

1.3.1 rollbackFor

我们在之前编写的业务方法上添加了@Transactional注解，来实现事务管理。

@Transactionalpublic void delete(Integer id){//根据部门id删除部门信息deptMapper.deleteById(id);//模拟：异常发生int i = 1/0;​//删除部门下的所有员工信息empMapper.deleteByDeptId(id);}

以上业务功能delete()方法在运行时，会引发除0的算数运算异常(运行时异常)，出现异常之后，由于我们在方法上加了@Transactional注解进行事务管理，所以发生异常会执行rollback回滚操作，从而保证事务操作前后数据是一致的。

下面我们在做一个测试，我们修改业务功能代码，在模拟异常的位置上直接抛出Exception异常（编译时异常）

@Transactionalpublic void delete(Integer id) throws Exception {//根据部门id删除部门信息deptMapper.deleteById(id);//模拟：异常发生if(true){throw new Exception("出现异常了~~~"); }​//删除部门下的所有员工信息empMapper.deleteByDeptId(id);}

说明：在service中向上抛出一个Exception编译时异常之后，由于是controller调用service，所以在controller中要有异常处理代码，此时我们选择在controller中继续把异常向上抛。

@DeleteMapping("/depts/{id}")public Result delete(@PathVariable Integer id) throws Exception {//日志记录log.info("根据id删除部门");//调用service层功能deptService.delete(id);//响应return Result.success();}

重新启动服务后测试：

抛出异常之后事务会不会回滚

现有表中数据：

使用postman测试，删除5号部门

发生了Exception异常，但事务依然提交了

dept表中数据：

通过以上测试可以得出一个结论：默认情况下，只有出现RuntimeException(运行时异常)才会回滚事务。

假如我们想让所有的异常都回滚，需要来配置@Transactional注解当中的rollbackFor属性，通过rollbackFor这个属性可以指定出现何种异常类型回滚事务。

@Slf4j@Servicepublic class DeptServiceImpl implements DeptService {@Autowiredprivate DeptMapper deptMapper;​@Autowiredprivate EmpMapper empMapper;​@Override@Transactional(rollbackFor=Exception.class)public void delete(Integer id){//根据部门id删除部门信息deptMapper.deleteById(id);//模拟：异常发生int num = id/0;​//删除部门下的所有员工信息empMapper.deleteByDeptId(id); }}

接下来我们重新启动服务，测试删除部门的操作：

控制台日志：执行了删除3号部门的操作， 因为异常又进行了事务回滚

数据表：3号部门没有删除

结论：

• 在Spring的事务管理中，默认只有运行时异常 RuntimeException才会回滚。

• 如果还需要回滚指定类型的异常，可以通过rollbackFor属性来指定。

1.3.3 propagation

1.3.3.1 介绍

我们接着继续学习@Transactional注解当中的第二个属性propagation，这个属性是用来配置事务的传播行为的。

什么是事务的传播行为呢？

• 就是当一个事务方法被另一个事务方法调用时，这个事务方法应该如何进行事务控制。

例如：两个事务方法，一个A方法，一个B方法。在这两个方法上都添加了@Transactional注解，就代表这两个方法都具有事务，而在A方法当中又去调用了B方法。

所谓事务的传播行为，指的就是在A方法运行的时候，首先会开启一个事务，在A方法当中又调用了B方法， B方法自身也具有事务，那么B方法在运行的时候，到底是加入到A方法的事务当中来，还是B方法在运行的时候新建一个事务？这个就涉及到了事务的传播行为。

我们要想控制事务的传播行为，在@Transactional注解的后面指定一个属性propagation，通过 propagation 属性来指定传播行为。接下来我们就来介绍一下常见的事务传播行为。

对于这些事务传播行为，我们只需要关注以下两个就可以了：

1. REQUIRED（默认值）

2. REQUIRES_NEW