关于spring嵌套事务，我发现网上好多热门文章持续性地以讹传讹
事情起因是，摸鱼的时候在某平台刷到一篇spring事务相关的博文，文章最后贴了一张图。里面关于嵌套事务的表述明显是错误的。
更奇怪的是，这张图有点印象。在必应搜索关键词PROPAGATION_NESTED出来的第一篇文章，里面就有这这部份内容，也是结尾部份完全一模一样。
更关键的是，人家原文是表格，这位倒好，估计是怕麻烦，直接给截成图片了。
而且这篇文章其实在评论区已经被人指出来这方面的问题了，谁也不能保证自己写的文章没有一点纰漏，但原作者并没有加以理会并修改错误。
这位转载作者呢也不加验证地直接拿走了。
这位转载作者可不是个小号，而是某年度的人气作者。
可能是有自己的公众号，得保持一定的更新频率？
好家伙，没经过验证，一部份错误的内容就这样被持续扩大传播了。
在必应搜索关键词PROPAGATION_NESTED出来文章，前两篇都是CSDN，都是一样的文章一样的错误。另外几篇文章也或多或少有些表述不清的地方。因此尝试来写一写这方面的东西。
顺便吐槽一下CSDN，我好多篇文章都被这上面的某些作者给扒过去，然后搜索一模一样的标题，权重比我还高，出来排第一位的反而是CSDN的盗版文章。
1.当我们在谈论嵌套事务的时候，嵌套的是什么？
当看到`嵌套事务`第一反应想到是这样式的：
但这更像PROPAGATION_REQUIRES_NEW啊，感兴趣可以去打断点执行一下。PROPAGATION_REQUIRES_NEW事务传播下，方法A调用方法B就是这样，
// 事务A doBegin()
// 事务B doBegin()
// 事务B doCommit()
// 事务A doCommit()
而在PROPAGATION_NESTED事务传播下，打了个断点，会发现只会执行一次doBegin和doCommit：
事务A doBegin()
事务A doCommit()
我们用代码输出更加直观。
定义两个方法serviceA和serviceB,使用前者调用后者。前者事务传播使用REQUIRED,后者使用PROPAGATION_NESTED。
@Transactional(propagation = Propagation.REQUIRED)
public void serviceA(){
Tcity tcity2 = new Tcity();
tcity2.setId(0);
tcity2.setStateCode("5");
tcity2.setCnCity("测试城市2");
tcity2.setCountryCode("ALB");
tcityMapper.insertSelective(tcity2);
transactionInfo();
test2.serviceB();
}
@Transactional(rollbackFor = Exception.class, propagation = Propagation.NESTED)
public void serviceB() {
Tcity tcity = new Tcity();
tcity.setId(0);
tcity.setStateCode("5");
tcity.setCnCity("测试城市");
tcity.setCountryCode("ALB");
tcityMapper.insertSelective(tcity);
tcityMapper.selectAll2();
transactionInfo();
这里的transactionInfo()使用事务同步器管理器TransactionSynchronizationManager注册一个事务同步器TransactionSynchronization。
这样在事务完成之后afterCompletion会输出当前事务是commit还是rollback，这样也便于测试，比起去刷新数据库看有没有写入，更加方便快捷直观。
同时使用TransactionSynchronizationManager.getCurrentTransactionName()可以得到当前事务的名称，这样可以直观的看到当前方法使用的是同一个事务还是不同的事务。
protected void transactionInfo() {
String transactionName = TransactionSynchronizationManager.getCurrentTransactionName();
boolean active = TransactionSynchronizationManager.isActualTransactionActive();
log.info("transactionName:{}, active:{}", transactionName, active);
if (!active) {
log.info("transaction ：{} not active", transactionName);
return;
}
TransactionSynchronizationManager.registerSynchronization(new TransactionSynchronization() {
@Override
public void afterCompletion(int status) {
if (status == STATUS_COMMITTED) {
log.info("transaction ：{} commit", transactionName);
} else if (status == STATUS_ROLLED_BACK) {
log.info("transaction ：{} rollback", transactionName);
} else {
log.info("transaction ：{} unknown", transactionName);
}
}
});
}
执行测试代码：
@RunWith(SpringRunner.class)
@SpringBootTest
public class Test {
@Autowired
private Test1 test1;
@org.junit.Test
public void test(){
test1.serviceA();
}
}
输出：
可以非常直观地观察到3点情况：
1.通过上图标记为1的地方，可以看到两个方法使用了一个事务com.nyp.test.service.propagation.Test1.serviceA。
2.通过上图标记为2的地方，以及箭头顺序，可以看到事务执行顺序类似于（事实上不是，只是事务同步器的问题，下文有说明）：
// 事务A doBegin()
// 事务B doBegin()
// 事务A doCommit()
// 事务B doCommit()
3.通过事务同步器打印日志发现commit执行了两次。
以上2，3两点与前面打断点的结论貌似是有点冲突。
1.1嵌套事务究竟有几个事务
源码版本:spring-tx 5.3.25
通过源码，可以很直观地观察到，useSavepointForNestedTransaction()默认返回true,这样就不会开启一个新的事务(startTransaction), 而是创建一个新的savepoint。
相当于在方法A的时候会开启一个新的事务，在调用方法B的时候，会在方法A之后方法B之前创建一个检查点。
类似于在原来的A方法上手动添加检查点。
@Transactional(propagation = Propagation.REQUIRED)
public void serviceA(){
Object savePoint = null;
try {
Tcity tcity2 = new Tcity();
tcity2.setId(0);
tcity2.setStateCode("5");
tcity2.setCnCity("测试城市2");
tcity2.setCountryCode("ALB");
tcityMapper.insertSelective(tcity2);
transactionInfo();
savePoint = TransactionAspectSupport.currentTransactionStatus().createSavepoint();
test2.serviceB();
} catch (Exception exception) {
exception.printStackTrace();
TransactionAspectSupport.currentTransactionStatus().rollbackToSavepoint(savePoint);
}
}
然后通过检查点，将一个逻辑事务分为多个物理事务。
我这可不是在乱讲啊，我是有备而来。
https://github.com/spring-projects/spring-framework/issues/8135
上面是spring 在github官方社区07年的一个贴子，Juergen Hoeller有一段回复。
Juergen Hoeller是谁？他是spring的联合创始人，事务这一块的主要开发者。
PROPAGATION_NESTED的不同之处在于，它使用具有多个保存点的单个物理事务，可以回滚到这些保存点。这种部分回滚允许内部事务范围触发其范围的回滚，而外部事务可以继续进行物理事务，尽管已经回滚了一些操作。这通常映射到JDBC保存点上，因此只适用于JDBC资源事务(Spring的DataSourceTransactionManager)。
在嵌套事务中，整体是一个逻辑事务，通过savepoint在jdbc物理层面把调用方法分割成一个个的物理事务。
因为spring层面只有一个逻辑事务，所以通过断点只执行了一次doBegin()和doCommit()，但实际上执行了两次preCommit()，如果有savepoint那就不执行commit(),
这也能回答上面2，3两点问题的疑问。
所以上面方法A调用方法B进行嵌套事务，右（下）图比左（上）图更形象准确：
1.2 savepoint
savepoint是JDBC的一种机制，spring运用savepoint来实现了嵌套事务。
在数据库操作中，默认autocommit为true，意味着一条SQL一个事务。也可以将autocommit设置为false，将多条SQL组成一个事务，一起commit或者rollback。
以上都是常规操作，在一个事务中所以数据库操作全部捆绑在一起。在某些特定情况下，在一个事务中，用户只希望rollback其中某部份，这时候可以用到savepoint。
记我们忘掉@Transactional，以编程式事务的方式来手动设置一个savepoint。
方法A，写入一条用户记录，并设置一个检查点。
@Autowired
private PlatformTransactionManager platformTransactionManager;
public void serviceA(){
TransactionStatus status = platformTransactionManager.getTransaction(new DefaultTransactionDefinition());
Object savePoint = null;
try {
Person person = new Person();
person.setName("张三");
personDao.insertSelective(person);
transactionInfo();
// 设置一个savepoint
savePoint = status.createSavepoint();
test2.serviceB();
} catch (Exception exception) {
exception.printStackTrace();
// 这里输出两次commit,到rollback到51行,会插入一条数据
status.rollbackToSavepoint(savePoint);
// 这里会两次rollback
// platformTransactionManager.rollback(status);
}
platformTransactionManager.commit(status);
}
方法B写入一条日志记录。并在此模拟一个异常。
public void serviceB() {
TLog tLog = new TLog();
tLog.setOprate("user");
transactionInfo();
tLogDao.insertSelective(tLog);
int a = 1 / 0;
}
测试希望达到的效果是，日志写入失败，但用户记录写入成功。很明显，如果不使用savepoint是达不到的。因为两个方法是一个事务，在方法B中报错了，抛出异常，用户和日志的数据库操作都将回滚。
测试输出日志：
[2023-04-24 14:40:18.740] INFO 88384 [main] [com.nyp.test.service.propagation.Test1] : transactionName:null, active:true
[2023-04-24 14:40:18.742] INFO 88384 [main] [com.nyp.test.service.propagation.Test2] : transactionName:null, active:true
java.lang.ArithmeticException: / by zero
......省略
[2023-04-24 14:40:18.747] INFO 88384 [main] [com.nyp.test.service.propagation.Test1] : transaction ：null commit
[2023-04-24 14:40:18.747] INFO 88384 [main] [com.nyp.test.service.propagation.Test2] : transaction ：null commit
数据库也表明用户写入成功，日志写入失败。
2.一开始的问题，B先回滚A再正常提交？
本文开始的问题是方法A事务传播为PROPAGATION_REQUIRED，方法B事务传播为PROPAGATION_NESTED。方法A调用B，methodA正常，methodB抛异常。
这种情况下会发生什么？
B先回滚，A再正常提交这种说法为什么会有问题，有什么问题？
2.1 先B后A的顺序有问题吗？
通过前面事务同步器打印的日志我们得知，事务以test1.serviceA()执行doBegin(),test2.serviceB()执行doBegin(),test1.serviceA()执行doCommit(),test2.serviceB()执行doCommit()这样的顺序执行。
但是果真如此吗？
通过源码我们首先得知，preCommit()在commit()方法之前，在preCommit()会做savepoint的判断，如果有检查点就不执行commit()。
- 同时方法B只是一个savepoint不是一个真正的事务，并不会执行事务同步器。
- 方法A是一个真正的事务，所以会执行commit(),同时也会执行上面的事务同步器。
这里的事务同步器是一个Arraylist,它的执行顺序即是arraylist的遍历顺序，仅仅只代表加入的先后，并不代表事务真正commit/rollback的顺序。
从1，2两点可以得出结论，先B后A的顺序并没有问题。
同时，根据1，在嵌套事务中使用事务同步器要特别小心，在检查点的时候并不会执行同步器，同时会掩盖真正的操作。
比如方法B回滚了，但因为方法B只是个savepoint，所以事务同步器不会执行。等到方法A执行完操作事务同步器的时候，也只会反应外层事务即方法A的事务结果。
2.2 真正的问题
如果B回滚，A是commit还是rollback取决于方法A是否继续把异常往上抛。
让我们先暂时忘掉嵌套事务，测试一个REQUIRES_NEW的案例。
同样的方法A事务传播为REQUIRES，方法B为REQUIRES_NEW。
此时方法A和方法B为两个彼此独立的事务。
方法A调用方法B，方法B抛出异常。
此时，方法B肯定会回滚，但方法A呢？按理说彼此独立，那肯定是commit了。
但真的如此吗？
(1). 方法A不做异常处理。
测试结果：
可以看到确实是两个事务，但两个事务都rollback了。因为方法A虽然没有报异常，但它接到了方法B的异常且往上抛了，spring只会认为方法A同样也抛出了异常。因此两个事务都需要回滚。
(2).方法A处理了异常。
将方法A代码try-catch住，再执行。
日志有点多不做截图，
[2023-04-24 16:10:30.669] INFO 96664 [main] [com.nyp.test.service.propagation.Test1] : transactionName:com.nyp.test.service.propagation.Test1.serviceA, active:true
[2023-04-24 16:10:30.672] INFO 96664 [main] [com.nyp.test.service.propagation.Test2] : transactionName:com.nyp.test.service.propagation.Test2.serviceB, active:true
[2023-04-24 16:10:30.687] INFO 96664 [main] [com.nyp.test.service.propagation.Test2] : transaction ：com.nyp.test.service.propagation.Test2.serviceB rollback
java.lang.ArithmeticException: / by zero
省略
[2023-04-24 16:10:30.689] INFO 96664 [main] [com.nyp.test.service.propagation.Test1] : transaction ：com.nyp.test.service.propagation.Test1.serviceA commit
可以看到两个单独的事务，事务B回滚了，事务A提交了。
虽然我们这小节说的是REQUIRES_NEW，但嵌套事务是一样的道理。
如果B回滚，当方法A继续往上抛异常，则A回滚；当方法A处理了异常不往上抛，则A提交。
3. 场景
在2.2小节中，我们举了REQUIRES_NEW的例子来说明，有的同学可能就会有点疑问了。既然事务B回滚了，事务A都要根据情况来判断是否回滚，那这样嵌套事务跟REQUIRES_NEW有啥区别？
还是拿注册的场景来说。往数据库写1条用户记录，再写1条注册成功操作日志。
- 如果日志写入失败，用户写入不受影响。这种情况下，
REQUIRES_NEW和嵌套事务都能实现。而且很明显REQUIRES_NEW还没那么弯弯绕绕。
2.考虑另外一种情况，如果用户写入失败了，那这时候我想要日志写入也失败。因为用户都没了，就不存在注册操作成功的操作日志了。
这种场景，在方法B为REQUIRES_NEW模式下，打印输出
可以看到方法B提交了，也就是说用户注册失败了，但用户注册成功的操作日志却写入成功了。
我们再来看看嵌套事务的情况下：
方法A传播级别为REQUIRED,并模拟一个异常。
@Transactional(propagation = Propagation.REQUIRED)
public void serviceA(){
Person person = new Person();
person.setName("李四");
personDao.insertSelective(person);
transactionInfo();
test2.serviceB();
int a = 1 / 0;
}
方法B事务传播级别为NESTED。
@Transactional(propagation = Propagation.NESTED)
public void serviceB() {
TLog tLog = new TLog();
tLog.setOprate("user");
transactionInfo();
tLogDao.insertSelective(tLog);
}
执行日志
可以看到同一个逻辑事务下的两段物理事务都回滚了，达到了我们预期的效果。
4.小结
1.方法A事务传播为REQUIRED，方法B事务传播为NESTED。方法A调用方法B，当B抛出异常时，
如果A处理了异常，此时事务A提交。否则，事务A回滚。
2.REQUIRED_NEW和NESTED在有些场景下可以实现相同的功能，但在某些特定场景下只能NESTED实现。
3.NESTED底层逻辑是JDBC的savepoint。父事务类似于一个逻辑事务，savepoint将各方法分割了若干物理事务。
4.在嵌套事务中使用事务同步器时需要特别小心。
看到这里点个赞呗`
