官网解释
https://seata.io/zh-cn/docs/user/appendix/isolation.html
看官网之前一定要分清官网中说的全局事务和本地事务,本地事务就是平时开发的时候
用@Transactional标注的方法,执行多个sql保证统一提交,利用的是数据库自身的事务
全局事务就是seata自带的事务,跨服务的事务,这两个分不清理解不好隔离,
在debug的时候,不要debug全部线程,因为有心跳到nacos,超过30秒就下线了,就会发生Feign找不到服务
1.本地事务修改了全局事务的数据,回滚问题
T1为全局事务,T2为本地事务
T1修改库存之后,还要生成订单,当生成订单的时候发生异常,但是T2本地事务不受全局事务的限制直接修改了库存,T1回滚库存服务的时候就异常,会一直重试直到超时.超时时间通过配置
server.maxRollbackRetryTimeout=-1 -1代表永不超时
测试
T1事务
T2调用库存服务修改库存数据
全局事务服务发起调用
T1修改库存服务之前剩余80
T1调用订单服务时debug,是要抛出异常的
T1修改库存剩余78,虽然T1此时没有提交全局事务,但是库存数据库已经提交(AT模式特性)
T2事务
修改库存(此时T1还没有提交,debug阻塞在生成订单服务)
数据库修改数据由78修改76
T1服务debug放开,因为抛出异常,通过TC通知库存服务重试回滚数据,因为修改后的数据为78,回滚的是判断当前数据是否为78,但是当前已经被T2修改未76,一直重试回滚,当我们手动的修改数据库为78时,具备回滚条件,将数据修改为T1事务之前的数据80
2.两个全局事务
示例1提到了,本地事务可以修改全局事务的数据,那能不能像本地事务那样阻塞住,T2等T1全局事务提交后,再继续执行T2呢,答案是可以的,只要将T2升级为全局事务,只是标注
@GlobalTransactional就可以了
在本地测试的时候,记着把垃圾数据清理,比如lock_table表,undolog表的数据都清理一下,不清理会提示数据被锁的给错误信息
当T2标注@GlobalTransactional就会提示错误
超时了,也是通过配置实现的,重试30次,每次10毫秒
client.rm.lock.retryInterval=10
client.rm.lock.retryTimes=30
client.rm.lock.retryPolicyBranchRollbackOnConflict=true
找了一下重试超时的源码,像这种一定是while(true)或者for(;;)加异常退出的方式
io.seata.rm.datasource.exec.LockRetryController#sleep
3.T1T2都为全局事务,T2为全局读
上面两个例子是写隔离,那读隔离呢
AT模式,都是先将数据commit,在回滚的时候才会把数据通过补偿的方式恢复,
如果T2为全局事务读取库存数据,查询语句为select * from stock where id = 1,
当T1全局事务还没有提交的时候,但是库存其实已经修改了,T2读取的也是修改之后的数据
其实希望的是,T1全局事务没有提交,即使库存数据已经修改了,还想读取未修改之前的数据,
官网上提到了 使用 for update的方式,这里就不详细的说明了,在git上都有,postman的请求也会发到git上
