浙大陆展团队突破铁催化难题，实现高效氢联硅化反应 | 乐研试剂
2026/1/16 22:01:30
Spring 事务嵌套：
异常：Transaction rolled back because it has been marked as rollback-only
原因：事务产生了嵌套，内部事务失败标记为rollback-only，但是异常捕获没有抛出，外层事务提交报错
解决方案：
1.自定义异常，不触发内部事务失败回滚
2.修改全局配置:isGlobalRollbackOnParticipationFailure为false
3.修改单个配置:在service层方法的catch语句中增加：TransactionAspectSupport.currentTransactionStatus().setRollbackOnly();语句，手动回滚
Spring事务@Transational：
| 属性 | 类型 | 描述 |
|---|---|---|
| value | String | 可选的限定描述符，指定使用的事务管理器 |
| propagation | enum: Propagation | 可选的事务传播行为设置 |
| isolation | enum: Isolation | 可选的事务隔离级别设置 |
| readOnly | boolean | 读写或只读事务，默认读写 |
| timeout | int (in seconds granularity) | 事务超时时间设置 |
| rollbackFor | Class对象数组，必须继承自Throwable | 导致事务回滚的异常类数组 |
| rollbackForClassName | 类名数组，必须继承自Throwable | 导致事务回滚的异常类名字数组 |
| noRollbackFor | Class对象数组，必须继承自Throwable | 不会导致事务回滚的异常类数组 |
| noRollbackForClassName | 类名数组，必须继承自Throwable | 不会导致事务回滚的异常类名字数组 |
Spring事务传播七种属性：
事务传播行为类型 | 说明 |
PROPAGATION_REQUIRED | （默认事务）需要事务。若当前无事务，新建一个事务；若当前有事务，加入此事务中。 |
PROPAGATION_SUPPORTS | 支持事务。若当前没有事务，以非事务方式执行；若当前有事务，加入此事务中。 |
PROPAGATION_MANDATORY | 强制使用事务。若当前有事务，就使用当前事务；若当前没有事务，抛出异常。 |
PROPAGATION_REQUIRES_NEW | 新建事务。无论当前是否有事务，都新建事务运行。 |
PROPAGATION_NOT_SUPPORTED | 不支持事务。若当前存在事务，把当前事务挂起，然后运行方法。 |
PROPAGATION_NEVER | 不使用事务。若当前方法存在事务，则抛出异常，否则继续使用无事务机制运行。 |
PROPAGATION_NESTED | 嵌套。如果当前存在事务，则在嵌套事务内执行；如果当前没有事务，则执行与PROPAGATION_REQUIRED类似的操作。 |
Spring事务隔离四种级别：
| @Transactional(isolation = Isolation.READ_UNCOMMITTED) | 读取未提交数据(会出现脏读， 不可重复读) 基本不使用 |
| @Transactional(isolation = Isolation.READ_COMMITTED)(SQLSERVER默认) | 读取已提交数据(会出现不可重复读和幻读) |
| @Transactional(isolation = Isolation.REPEATABLE_READ) | 可重复读(会出现幻读) |
| @Transactional(isolation = Isolation.SERIALIZABLE) | 串行化 |
工作原理：
自动提交
默认情况下，数据库处于自动提交模式。每一条语句处于一个单独的事务中，在这条语句执行完毕时，如果执行成功则隐式的提交事务，如果执行失败则隐式的回滚事务。
事务管理，是一组相关的操作处于一个事务之中，因此必须关闭数据库的自动提交模式。spring会在org/springframework/jdbc/datasource/DataSourceTransactionManager.java中将底层连接的自动提交特性设置为false。
spring事务回滚规则
指示spring事务管理器回滚一个事务的推荐方法是在当前事务的上下文内抛出异常。spring事务管理器会捕捉任何未处理的异常，然后依据规则决定是否回滚抛出异常的事务。
默认配置下，spring只有在抛出的异常为运行时unchecked异常时才回滚该事务，也就是抛出的异常为RuntimeException的子类(Errors也会导致事务回滚)，而抛出checked异常则不会导致事务回滚。
可以明确的配置在抛出那些异常时回滚事务，包括checked异常。也可以明确定义那些异常抛出时不回滚事务。
还可以编程性的通过setRollbackOnly()方法来指示一个事务必须回滚，在调用完setRollbackOnly()后你所能执行的唯一操作就是回滚。
注意事项
- @Transactional 注解应该只被应用到public 可见度的方法上。 如果你在 protected、private 或者 package-visible 的方法上使用 @Transactional 注解，它也不会报错， 但是这个被注解的方法将不会展示已配置的事务设置。
- 用 spring 事务管理器，由spring来负责数据库的打开，提交，回滚。默认遇到运行期异常(throw new RuntimeException("注释");)会回滚，即遇到不受检查（unchecked）的异常时回滚；而遇到需要捕获的异常(throw new Exception("注释");)不会回滚，即遇到受检查的异常（就是非运行时抛出的异常，编译器会检查到的异常叫受检查异常或说受检查异常）时，需我们指定方式来让事务回滚 要想所有异常都回滚，要加上@Transactional( rollbackFor={Exception.class，其它异常})。
- @Transactional 注解可以被应用于接口定义和接口方法、类定义和类的 public 方法上。然而，请注意仅仅 @Transactional 注解的出现不足于开启事务行为，它仅仅是一种元数据，能够被可以识别 @Transactional 注解和上述的配置适当的具有事务行为的beans所使用。
- Spring团队的建议是你在具体的类（或类的方法）上使用 @Transactional 注解，而不要使用在类所要实现的任何接口上。你当然可以在接口上使用 @Transactional 注解，但是这将只能当你设置了基于接口的代理时它才生效。因为注解是不能继承的，这就意味着如果你正在使用基于类的代理时，那么事务的设置将不能被基于类的代理所识别，而且对象也将不会被事务代理所包装（将被确认为严重的）。因此，请接受Spring团队的建议并且在具体的类上使用 @Transactional 注解。
- @Transactional 注解标识的方法，处理过程尽量的简单。尤其是带锁的事务方法，能不放在事务里面的最好不要放在事务里面。可以将常规的数据库查询操作放在事务前面进行，而事务内进行增、删、改、加锁查询等操作。
- @Transactional 注解的默认事务管理器bean是“transactionManager”，如果声明为其他名称的事务管理器，需要在方法上添加@Transational("managerName")。
- @Transactional 注解标注的方法中不要出现网络调用、比较耗时的处理程序，因为，事务中数据库连接是不会释放的，如果每个事务的处理时间都非常长，那么宝贵的数据库连接资源将很快被耗尽。
参考：https://www.cnblogs.com/wonder2636/p/9444556.html