Spring的事务的传播行为

Spring 事务公用7种传播行为，来保证事务的正常执行。spring的这其中传播行为是spring通过事务提交方式等来实现的事务多样化控制，数据库本身是没有这些行为的。七种具体如下：

1. REQUIRED: 默认的传播特性，如果当前没有事务，就新建一个事务，如果当前存在事务，就加入这个事务。
   [如果你写了作业，我就抄你的作业，如果你没写我就自己写。]
   
    
2. SUPPORTS: 当前存在事务，则加入当前事务，否则以非事务的方式执行。
   [如果你写了作业，我就抄你的作业，如果你没写我也不写。怕啥，大不了一起挨屁屁]
   
    
3. MANDATORY: 当前存在事务，则加入事务，如果当前事务不存在，则抛出异常。
   [如果你写了作业，那我抄你的作业，如果你没写我就给你妈告你，谁叫你害的我也交不了作业。]
   
   
   
   
4. REQUIRED_NEW: 创建一个新事物，如果存在当前事务，则挂起该事务。
   [不管你写没写作业，我都自己写作业，我交了作业你才能交，要是我写不出来，你也别想交作业。]
   
   Test Case1: 
   
   
   
   测试结果可以发现，虽然saveTableB已经独立成了新事物，但是由于saveTableB的方法跑出去的错，saveTableA的方法作为调用方没有try catch，就会导致外层事务也会继续抛出异常，导致同样失败。
   
   Test Case 2:
   
   
   
   对比test case 1.我们就可以发现子事务的失败回滚并未导致外层主事务失败。
   
   
   Test Case 3: 
   
   
   可以发现外层事务也就是主事务回滚了，但是子事务已经提交是不受影响的。
   
5. NESTED: 如果当前事务存在，则在嵌套事务中执行，否则同REQUIRED。
   [如果你写了作业，你写的你先保存在哪里，等我确定我也能写出作业，你再提交你的作业，你提交之后我再提交。如果我的作业写完了，叫你提交你的作业的时候，你发现你还有一道题没做，你需要接着做，但是你接着做的时候发现做不来，我也帮不了你，算了我们都不交作业了]
   
6. NOT_SUPPORT: 以非事务方式执行，如果存在当前事务，则挂起当前事务。
   [我不写作业，你正在写作业，我要求你停下来，陪我玩了，你再去写作业。反正我不写。]
   
   测试如下：当我们发送请求后，可以发现tableA没有保存成功，而tableB是非事务执行的可以保存成功
   
   
   
7. NEVER: 不使用事务，如果当前事务存在，则抛出异常。
   [我不写作业，你也不能写]
   
   
   
   

 

 

 

 

更多事务相关：
Spring事务的代理对象特性_TGO-Ming的博客-CSDN博客