Dear Seata Team, I am currently working on the issue mentioned below, and there are some points that I believe would benefit from further discussion.
Issue link <https://github.com/apache/incubator-seata/issues/6561> This issue addresses an endless loop that occurs during the rollback process. In the comments, it’s suggested that this situation be treated as a dirty write and that retries should be performed periodically. However, I believe there may be a better solution. 1. Limiting the Number of Retries Similar to JUnit5's failureThreshold, setting a limit on the number of retries could be an effective approach. JUnit5 RepeatedTestExtension Reference <https://github.com/junit-team/junit5/blob/0c6478200fe2acbcb68e286252d107899eda53e4/junit-jupiter-engine/src/main/java/org/junit/jupiter/engine/extension/RepeatedTestExtension.java#L65-L75> Limiting the retries to a specific number, rather than retrying indefinitely, would help use system resources more efficiently. 2. Gradually Increasing Retry Interval Another approach to consider is gradually increasing the retry interval. >From a system resource perspective, this approach could be more effective as it allows for retries without overburdening the system. However, limiting the number of retries could potentially lead to the process being terminated before the issue is resolved, which might disrupt normal system operation. Additionally, determining the optimal number of retries could be challenging. Also, gradually increasing the retry time could result in longer time to resolve the issue, which is a disadvantage to consider. I would appreciate discussing these trade-offs to make a more informed decision. Best regards, Yongjun github/yongjun : https://github.com/YongGoose PS. Although the issue hasn’t been assigned to me yet, I started working on it after noticing that currently there were no updates and the PR was closed. Xīnnián kuàilè 🙂
