xinfan.wu
xinfan.wu
plz assign this issue to me @dongzl
正常流程异常处理提交过程1.PREPARE下发之前有节点失败或报错，关闭连接放弃事务数据 2.PREPARE下发过程中发生失败，则回滚事务，所有节点下发ROLLBACK 3.如果在COMMIT阶段发生失败，则尝试重试（重试次数需做限制或者开放给用户设置），几次尝试失败或者超出期望时间将事务交给定时任务（补偿机制）回滚过程如果在ROLLBACK阶段发生失败，则尝试重试（重试次数需做限制或者开放给用户设置），几次尝试失败或者超出期望时间将事务交给定时任务（补偿机制）异常流程补偿机制假如出现由于服务下线或者其他原因导致的提交或回滚任务被执行了一半（突然断连），在这种情况发生的时候需要有对应的补偿机制来保证数据的最终一致性。要点：补偿事务本身也是一个最终一致性操作，因此也可能会失败。因此补偿事务中的步骤应该是幂等的。首先看事务的状态： 状态 | 解释 -- | -- TX_STARTED_STATE | XA事务处于开始状态，在事务开始直到提交或者回滚之前XA事务的状态一直会保持此状态 TX_PREPARING_STATE | XA 事务正在下发prepare TX_PREPARED_STATE | XA PREPARED成功状态 TX_COMMITTING_STATE | XA 事务正在提交 TX_ROLLBACKING_STATE | XA 事务正在回滚 TX_COMMITTED_STATE |...
already solved， this issue can be closed
There are two questions. The first is why memory leaks occur here. The other question is that pooling can improve memory utilization but it does not seem to fundamentally guarantee...
> @No-SilverBullet @FoghostCn I updated URL.Clone() in common/url.go to use defer for lock releases and added nil checks for params and attributes as per the suggestions. Additionally, I enhanced TestSubURLCopy...
Have you pull the newest upsteam/develop branch? CI error still exists.
we can move some clients's logo images to discussions, and link it in Doc
我们正在跟进这个问题，PR将会在最近提 @1kasa
我们会在new-triple协议支持 @marsevilspirit