spring事务传播行为

先来看一个假设方便理解

辅助：主动光环：可以给队友回血回蓝

c(主要输出伤害)：主动复苏：可以回血回蓝而且比光环更快

​ 主动霸体：增加韧性硬直，抵御一切buff包括增益和减益

c的主动技能复苏和辅助的光环不可以叠加，

c是否去吃辅助的buff完全由c自己决定，可以开霸体拒绝，也可以使用自己的复苏

c对辅助的光环buff即为buff传播行为

buff行为：

c在辅助的光环的笼罩之下

1. 传播：起码发生在两个角色之间
2. c被辅助包裹
3. c是否接收辅助的光环，由c自己决定
4. c的决策方案即为事务传播行为属性：可以接受，可以不接受，也可以自己搞一个

事务传播行为

事务传播行为：

事务方法A被事务方法B调用，事务方法即为增删改的方法

事务方法A：事务协调员

事务方法B：事务管理员

1. 传播就是b的事务传播给A
2. A对待B的事务的态度即为传播属性

事务管理员即为例子中的辅助，事务协调员即为c

事务协调员处于事务管理员的笼罩中

• requirerd

  • 当辅助开启光环 c直接享受光环的增益
  • 辅助没开启光环，c使用自己的复苏

• requires_new

  • c快死掉了，光环的增益不够回复，无论辅助是否开启光环，都使用自己更快的复苏

• supports

  • c不缺状态，辅助开了光环就吃buff，没有就算了

• not_supported

  c都不要

• mandatory

  • 辅助开光环就加入
  • 辅助不开就死球，然后喷辅助菜

• never

  • c压血线增加攻击力，辅助给光环就死球

  • 不给就正常

  • 运用场景举例

  1. 还是以转账操作为例 : S(事务管理员)
     • 子业务S1：银行记录转账日志到数据库表X (事务协调员S1)
     • 子业务S2：X用户执行传出操作,修改表(事务协调员S2)
     • 子业务S3：Y用户执行转入操作,修改表(事务协调员S3)
  2. 执行过程
     假设S业务在执行过程中
     S的子业务S1成功, 但是S2或S3事务提交失败(S如果开启事务就要回滚,表示转账业务失败)
     S2和S3肯定需要回滚,因为这是转账的关联操作(如果S开启事务,此时设置S2,S3加入S事务即可,如果S没有开启事务,S2和S3就要自己开启新事务) --> REQUIRED
     不过S1是不需要跟着回滚,日志是起到记录作用的,失败了也要记录,以便解决,那么S1需要单独的一个新事务
     –> REQUIRES_NEW

package com.cxf.test.bean;

import org.springframework.stereotype.Service;
import org.springframework.transaction.annotation.Propagation;
import org.springframework.transaction.annotation.Transactional;
@Service
public class test2 {
    @Transactional
    public void s(){
        s1();
        s2();
        s3();
    }
    //银行转账日志，即使转账失败也不需要删除
    @Transactional(propagation = Propagation.REQUIRES_NEW)
    public void s1(){

    }
    //出账
    @Transactional(propagation = Propagation.REQUIRED)
    public void s2(){

    }
    //入账
    @Transactional(propagation = Propagation.REQUIRED)
    public void s3(){

    }
}

使用规范

1. 一般增删改：加事务 REQUIRED (默认取值)
2. 一般查询：不加事务 SUPPORTS
3. 非主要业务不对主业务造成影响：REQUIRES_NEW
4. 必须在有事务的环境运行：MANDATORY