前沿
–
一段生产事故发人深省,在Spring的声明式事务中手动捕获异常,居然判定回滚了,这是什么操作?话不多说直接上代码
@Service
public class A {
@Autowired
private B b;
@Autowired
private C c;
@Transactional(propagation = Propagation.REQUIRED, isolation = Isolation.DEFAULT)
public void operate() {
try {
b.insertB();
c.insertC();
}catch (Exception e) {
e.printStackTrace();
}
}
}
@Service
public class B {
@Autowired
private BM bm;
@Transactional(propagation = Propagation.REQUIRED)
public int insertB() {
return bm.insert(“B”);
}
}
@Service
public class C {
@Autowired
private CM cm;
@Transactional(propagation = Propagation.REQUIRED)
public int insertC() {
return cm.insert(“C”);
}
}
复制代码
问题阐述
好了大家都看到上面这段代码了,在正常的情况的我们会往B表和C表中各插入一条数据,那么当代码出现异常时又会怎么样呢?
我们现在假设B插入数据成功,但是C插入数据失败了,此时异常会上抛到A,被A中operate
方法的try - cache所捕获,正常来说此时数据库中B能插入一条记录,而C表插入失败,这是我们期望的情况,但事实却不是,实际情况是B表没有插入数据,C表也没有插入数据,也就是说整个操作被Spring给回滚了
注意点
如果代码稍稍变动一下,将try - cache放在
insertC
的代码块中,在同样的场景下,B中会成功插入一条记录
知识点前置条件
了解Spring的传播机制的可以直接跳过
我们先要搞清楚Spring中的
REQUIRED
的作用
REQUIRED:如果当前没有事务就创建一个新的事务,如果当前已经存在事务就加入到当前事务
也就是说当我们的传播机制同时为
REQUIRED
时,A、B、C三者的事务是共用一个的,只有当A的流程全部走完时才会做一次commit或者rollback操作,不会在执行B或者C的过程中进行commit和rollback
问题追踪
好,有了一定的知识储备,我们一起来看源码
我们首先找到Spring事务的代理入口TransactionInterceptor
, 当我们通过调用A类中的operate
方法时会调用TransactionInterceptor
的invoke
方法,这是整个事务的入口,我们直接看重点invoke
中的invokeWithinTransaction
方法
//获取事务属性类 AnnotationTransactionAttributeSource
TransactionAttributeSource tas = getTransactionAttributeSource();
//获取事务属性
final TransactionAttribute txAttr = (tas != null ? tas.getT