Hi Yongjun, regarding issue #6561, the problem actually arises because the unique index is being occupied. In the current AT mode transaction, the rollback only checks whether the row data has changed after the first-phase commit to determine if there has been a dirty write. However, for deleted rows, there are no modified rows after the first-phase commit. So, when the deleted row data needs to be rolled back in the second phase to restore it, if its unique index column is occupied by other row data, it should be considered a dirty write and not rolled back. However, currently, the rollback continues indefinitely and always encounters a unique index conflict exception, leading to failure.
Regarding your proposed solution, retry limits and intervals are already handled by the existing configurations server.maxCommitRetryTimeout and server.maxRollbackRetryTimeout. However, these configurations apply at the global transaction level and cannot be applied to branch transactions. Additionally, the issue in question cannot be solved by retrying. Therefore, the two solutions you proposed are not the best approach to resolve this issue. In fact, the problem can be resolved simply by catching the SQLIntegrityConstraintViolationException exception and returning PhaseTwo_RollbackFailed_Unretryable. Best Regards！ Jianbin Chen, github-id: funky-eyes Yongjun Hong <[email protected]> 于 2025年1月31日周五 16:15写道： > 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è 🙂 >
