ethantsien
ethantsien
@success 200 {object} jsonresult.JSONResult{data=nil} "desc" data should be nil, nil will be json null but this feature does not work
> Expect admin page authentication. no need, use nginx auth basic
> > 是的，barrier可以保证幂等，但是你在barrier记录失败之后，又设置TccBTransInTry 执行成功，这就矛盾了，barrier记录失败之后，永远不再会返回成功了 > > 假设 TccBTransInTry 是一个扣金币的动作，TccBTransOutTry 成功了，TccBTransInTry失败了（金币不足），然后TccBTransOutRollback，在submit全局事务之前，程序崩溃了（用debug调试运行，在submit全局事务之前退出）。之后重启程序，dtm服务器那边resume，这个时候会重新调用 TccBTransOutTry , barrier会直接返回成功（不会真正执行TccBTransOutTry），TccBTransInTry 此时也成功（此时金币足够了），之后就会执行 TccBTransOutCommit 和 TccBTransInCommit，相当于 TccBTransIn既执行了rollback也执行了commit > > > 通过以上的方式手动模拟金币不足返回错误的情况 > > @yedf2 barrier和业务逻辑用同一个sql.Tx，就不会出现你说的这种情况
> TccBTransOutRollback 在崩溃前，执行成功了没有？如果成功了，dtm恢复以后是直接走rollback流程，而不是像你说的，重新从try再走一遍流程
而且try是客户端触发的，try再执行一次，就是一个新的事务
你搞错了，try是ap端直接call的，tm不会去call try，何来从头开始。ap重新call try，就要注册一个新的gid，就是一个新事物了。
你一个事务分支的rollback都执行过了，还要让ap从try再跑一遍？你这流程就不是dtm的流程。你就要让dtm把当前这个事务rollback完，ap端重新发起一次新的事务，而不是原来的事务重新从try跑一遍。
tcc协议中定义为commit和rollback必须成功，你不能重新从try跑一遍事务
这跟workflow没关系，workflow也是几个协议的组合，saga的补偿操作，Tcc的Confirm/Cancel操作，协议上规定，不能允许失败。
routes.go and types.go should not be modified, because a lot of content here is often adjusted in actual business, once modified, it cannot be automatically generated, so I think it...