We read every piece of feedback, and take your input very seriously.
To see all available qualifiers, see our documentation.
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
sharding-jdbc支持的两种柔性事务TCC和最大努力, 我理解一个是反向补偿,一个是正向重试,后者假设2个参与者,1个成功,一个失败,失败的哪个如果是逻辑冲突如主键重复了,怎么重试都会失败,基础设施问题,重启后恢复了,可能重试成功,但间隔较大,这期间告诉客户端事务是中间状态? TCC 2个参与者,1个成功,一个失败,会立即都反向补偿,如果是逻辑原因的,可理解补偿。如果是基础设施,好的那个参与者可以补偿。也就是最大努力下逻辑错误,重试也不行,基础设施故障能重试成功取决于基础设施恢复要多久,TCC下,逻辑错误,基础实施故障都能回退。那么最大努力正向重试除了对应用透明,还有何优势而言呢?
The text was updated successfully, but these errors were encountered:
讨论问题请使用qq群或wiki,请尽量保持issue有实际意义,尽量可以通过issue展现项目发展的进度历程。
Sorry, something went wrong.
No branches or pull requests
sharding-jdbc支持的两种柔性事务TCC和最大努力, 我理解一个是反向补偿,一个是正向重试,后者假设2个参与者,1个成功,一个失败,失败的哪个如果是逻辑冲突如主键重复了,怎么重试都会失败,基础设施问题,重启后恢复了,可能重试成功,但间隔较大,这期间告诉客户端事务是中间状态?
TCC 2个参与者,1个成功,一个失败,会立即都反向补偿,如果是逻辑原因的,可理解补偿。如果是基础设施,好的那个参与者可以补偿。也就是最大努力下逻辑错误,重试也不行,基础设施故障能重试成功取决于基础设施恢复要多久,TCC下,逻辑错误,基础实施故障都能回退。那么最大努力正向重试除了对应用透明,还有何优势而言呢?
The text was updated successfully, but these errors were encountered: