目录
一、事务的定义和意义
事务的定义
将⼀组操作封装成⼀个执⾏单元（封装到⼀起），要么全部成功，要么全部失败。
简单来说：事务诞生的目的就是为了把若干个独立的操作给打包成一个整体。
我们需要注意的是： Spring 的事务 相比于 MySQL 中的事务，要复杂一些！MySQL 的事务 无非就是 事务可以并发执行，需要考虑隔离性的问题。
但是！MySQL 的事务 非常单纯！
它不会说出现事务嵌套的问题。
比如：事务 A 嵌套了 事务 B，事务 B 嵌套了 事务 C，事务 C。。。。。
这种情况，在MySQL事务中是不会出现的。
Spring 的事务，就大不一样了！
因为我们代码，通常完成一个业务逻辑（事务），需要调用多个方法（事务），才能执行。
而多个多个方法又可能依赖于其他的方法，才得以实现。
这种情况，在 代码中 是非常常见的。
如果程序中出现这中嵌套的现象的话。
没问题的话，那还好，没有问题，
但是！万一出现了问题，那我们其它事务（方法）应该怎么去处理呢？
是相互不影响吗？ 一个事务（方法）出现了问题，其它的事务不受影响。
还是 “引火上身”呢？一个事务牵扯到 ABC 三个事务，如果 一个事务出现了问题，其它的事务是是无法执行的，直接给你 进行 事务回滚了！
这个就涉及到 Spring 事务传播的机制是怎么设置的了
二、事务的实现
1、MySQL事务的回顾
2、Spring声明式事务（利⽤注解⾃动开启和提交事务）
前置知识及概念
Spring 中的事务操作分为两类：
1、编程式事务（⼿动写代码操作事务）
编程式事务：通过代码来控制事务的 开启 和 提交，或者是 回滚。
2、 声明式事务（利用注解自动开启和提交事务）声明式事务的实现很简单，只需要在需要的⽅法上添加 @Transactional 注解就可以实现了，⽆需⼿动开启事务和提交事务，进⼊⽅法时⾃动开启事务，⽅法执⾏完会⾃动提交事务，如果中途发⽣了没有处理的异常会⾃动回滚事务
默认情况下，只有来自外部的方法调用才会被AOP代理捕获，也就是，类内部方法调用本类内部的其他方法并不会引起事务行为，即使被调用方法使用@Transactional注解进行修饰。
@Transactional 可以⽤来修饰⽅法或类：
- 修饰⽅法时：需要注意只能应⽤到 public ⽅法上，否则不⽣效。推荐此种⽤法。
- 修饰类时：表明该注解对该类中所有的 public ⽅法都⽣效。
Spring的事务管理默认是针对***unchecked exception**回滚，也就是默认对Error异常和RuntimeException异常以及其子类进行事务回滚，且必须抛出异常，若使用try-catch对其异常捕获则不会进行事务回滚操作
因此
- 对于unchecked exception（Error和RuntimeException异常）抛出时不需要方法调用throws或try-catch语句
- 而checked exception 则必须用try语句块进行处理或者把异常交给上级方法处理，总之就是必须写代码处理它，所以必须在service捕获异常，然后再次抛出，这样事务方才起效。
关于异常详情见：异常
实例分析：事务的回滚
我们通过url模拟添加操作
那么如果出现了异常，数据库中会不会添加这一条就记录呢？
可以看到，我们再浏览器的url输入的lisi这条记录，没有成功添加到数据库中。
原因就是@Transactional 注解的自动回滚操作——》通过该注解，我们⽆需⼿动开启事务和提交事务，进⼊⽅法时⾃动开启事务，⽅法执⾏完会⾃动提交事务，如果中途发⽣了没有处理的异常会⾃动回滚事务
????特殊情况（无自动回滚）
我们再浏览器里继续上面的操作（尝试添加一条lisi的记录，看看有什么变化）
可以看到数据库中有了lisi这条数据——》@Transactional 在异常被捕获的情况下，不会进⾏事务⾃动回滚。
????事务不会⾃动回滚解决⽅案
- 解决⽅案1：对于捕获的异常，事务是会⾃动回滚的，因此解决⽅案1就是可以将异常重新抛出
- 解决⽅案2：⼿动回滚事务，在⽅法中使⽤ TransactionAspectSupport.currentTransactionStatus() 可以得到当前的事务，然后设置回滚⽅法 setRollbackOnly 就可以实现回滚
????@Transactional工作原理
@Transactional 是基于 AOP 实现的，AOP ⼜是使⽤动态代理实现的。如果⽬标对象实现了接⼝，默认情况下会采⽤ JDK 的动态代理，如果⽬标对象没有实现了接⼝,会使⽤ CGLIB 动态代理。
@Transactional 在开始执⾏业务之前，通过代理先开启事务，在执⾏成功之后再提交事务。如果中途遇到的异常，则回滚事务。
@Transactional 实现思路预览：
三、Spring事务传播机制
1、事务的隔离级别及传播机制的引入
Spring 中事务隔离级别包含以下 5 种
1. Isolation.DEFAULT：以连接的数据库的事务隔离级别为主。
2. Isolation.READ_UNCOMMITTED：读未提交，可以读取到未提交的事务，存在脏读。
3. Isolation.READ_COMMITTED：读已提交，只能读取到已经提交的事务，解决了脏读，存在不可重复读。
4. Isolation.REPEATABLE_READ：可重复读，解决了不可重复读，但存在幻读（MySQL默认级别）。
5. Isolation.SERIALIZABLE：串⾏化，可以解决所有并发问题，但性能太低
从上述介绍可以看出，相⽐于 MySQL 的事务隔离级别，Spring 的事务隔离级别只是多了⼀个
Isolation.DEFAULT（以数据库的全局事务隔离级别为主）
为什么需要事务的传播机制
- 事务隔离级别是保证多个并发事务执⾏的可控性的（稳定性的）.
- 而事务传播机制，是保证⼀个事务在多个调⽤⽅法间的可控性的（稳定性的）
Spring 事务传播机制定义了多个包含了事务的⽅法，相互调⽤时，事务是如何在这些⽅法间进⾏传递的。
我们之前学习的事务都很简单，都是单个的事务。
各个事务之间是没有关联关系，并且不存在相互调用的情况。
但是！这种美好的情况，只是发生在 我们学习 Spring 框架之前。
之前我们的事务 是在数据库里面去操作的，没有问题！
单个事务，很简单。很纯粹！
但是呢，我们现在到了具体的业务方法里面，具体框架里面，它的业务场景就会变成复杂很多！
就比如：A方法调用 B 方法，B方法里面又调用了 C 方法。。。。
ABC。。。都有事务.
现在问你： 事务，它应该怎么样进行传递 和 怎么样去执行。
是每个事务各自运行，互不影响；
还是几个事务 组成一个大事务；
还是说，我不以事务的方式执行。
这种可能性是完全可能存在的。
比如：
A 调用 B，B 调用 C，C 调用 D.
然后呢，A有事务，B有事务，C 没事务，D 有事务。
好，这个时候，我们该怎么办？
我的事务要不要传，毕竟 C 没有事务，中间 “ 断了 ”。
这样的话，情况就异常复杂了。
这就是一个应用级程序 的 特性。
这东西很复杂！
因为 它没有那么纯粹，没有那么简单！
这时就用到我们事务的传播机制了
2、事务的传播机制
Spring 事务传播机制定义了多个包含了事务的⽅法，相互调⽤时，事务是如何在这些⽅法间进⾏传递的。
Spring 事务传播机制包含以下 7 种：
1、 Propagation.REQUIRED：
默认的事务传播级别，它表示如果当前存在事务，则加⼊该事务；如果当前没有事务，则创建⼀个新的事务。这就跟现在结婚的现状是一样的，房子（事务）是必须项、
女方就是 隔离级别 Propagation.REQUIRED
男方有房子，我就住进去。
反之，男方没有房子，也没关系。
一起奋斗买间房。
总之，房子必须有。2、 Propagation.SUPPORTS：
如果当前存在事务，则加⼊该事务；如果当前没有事务，则以⾮事务的⽅式继续运⾏。放在上面的例子中，这种女生更难求。
就是说：男方有没有房子都无所谓，就想和他结婚。
至于房子如果有，我就住。
没有，租房也行。3、Propagation.MANDATORY：
（mandatory：强制性）如果当前存在事务，则加⼊该事务；如果当前没有事务，则抛出异常。这种情况，就非常的现实。
如果男方没有房，就不结婚，甚至直接分手。
反之，女方就直接住进去。【加名，迟早会提出来的。】
总之，房子必须有，男方全款买。4. Propagation.REQUIRES_NEW：
表示创建⼀个新的事务，如果当前存在事务，则把当前事务挂起。
也就是说不管外部⽅法是否开启事务，Propagation.REQUIRES_NEW 修饰的内部⽅法会新开启⾃⼰的事务，且开启的事务相互独⽴，互不⼲扰。这种情况，女生非常作！
男生已经买了房，只不过可能有个 一两年的历史
女方表示必须是新房，旧房我不住！
不是新房，我不接了！！！5. Propagation.NOT_SUPPORTED：
以⾮事务⽅式运⾏，如果当前存在事务，则把当前事务挂起。这种情况，女方比较奇葩。
就算男方有房子，也不住。
我就是要住 租的房子！6. Propagation.NEVER：
以⾮事务⽅式运⾏，如果当前存在事务，则抛出异常。这种就更奇葩。
男方有房子，这婚我不接了！分手！
男方没有房子，真好！我要和你结婚。7. Propagation.NESTED：
如果当前存在事务，则创建⼀个事务作为当前事务的嵌套事务来运⾏；
如果当前没有事务，则该取值等价于 PROPAGATION_REQUIRED（创建一个新事物）。这种就是 白富美剧情。
男方有房，女方家里又给了一套房。
如果男方没有房，女方家里表示我可以送一套！
REQUIRED需要有（事务的默认传播机制）和NESTED嵌套事务的区别：
1) REQUIRED需要有他是如果当前方法存在事务，把当前方法的事务加入到之前的那个事务当中，一荣俱荣，一损俱损（两个事务直接是一个整体，如果其中有任何一个事务有问题，这两个事务作为一个整体都不会执行）——》所有是事务都加到了一个大的事务里面了。
2) NESTED嵌套事务则不同，事务直接不是一个整体，是相互嵌套着的。如果当前存在事务，把当前事务嵌套到之前的事务中来这些，如果当前事务存在异常（只是影响发生异常的这一个事务，不影响其他事务）
3、事务的隔离级别和事务的传播机制的区别
事务隔离级别是保证多个并发事务执⾏的可控性的（稳定性的），⽽事务传播机制是保证⼀个事务在多个调⽤⽅法间的可控性的（稳定性的）
事务隔离级别解决的是多个事务同时调⽤⼀个数据库的问题
事务传播机制解决的是⼀个事务在多个节点（⽅法）中传递的问题（或多个事务的嵌套和互相加入）
如果是多个事务，在相互调用的情况，也很好理解！
事务的传播机制，在多个事务相互调用的时候，对其进行“行为控制”，让其结果能够达到我们预期的效果。
我们还可以发现，在事务的传播机制中，多个事务都在 “一条线上”。
那么，问题来了：
正如我们前面所说: 如果这三个事务中，有一个事务 只是一个普通方法，不具备事务。使其 事务的传递 中断，我们该怎么做？是全部回滚，将数据恢复到未操作状态。
还是说，那个事务出现了问题，就回滚那个事务。
或者，不回滚。
这些都是不确定的因数！
这些都是：婆说婆有理，公说公有理。
无论你怎么说，你都有你的道理。
但是！不管怎么说，我们都需要一个统一行为，或者说 一个统一的管理模式。【放在上面例子中，就是要有一个 客观的标准】
这就必须要依靠事务传播机制，依靠 设置 和 规定，来去处理。
参考文章：
SpringBoot 使用 @Transactional 注解配置事务_深寒色的猫丶的博客-CSDN博客
JavaEE进阶 - Spring事务和事务传播机制 - 细节狂魔_java事务传播机制_Dark And Grey的博客-CSDN博客