Why you need it?
Is your feature request related to a problem? Please describe in details
生成afterImage的时候用的 (id，...) in (1,...)，在用sharding时无法路由到对应的表，造成所有库所有表都扫描了。影响性能
另tc建议加个定时扫描针对rollback失败超过多少次或者多少时间的接入下通知（丁丁或者啥），也不用每个业务方自己扫描undo log了
How it could be?
A clear and concise description of what you want to happen. You can explain more about input of the feature, and output of it.
Other related information
Add any other context or screenshots about the feature request here.
6条答案
按热度按时间oipij1gg1#
Why you need it?
Is your feature request related to a problem? Please describe in details
生成afterImage的时候用的 (id，...) in (1,...)，在用sharding时无法路由到对应的表，造成所有库所有表都扫描了。影响性能
另tc建议加个定时扫描针对rollback失败超过多少次或者多少时间的接入下通知（丁丁或者啥），也不用每个业务方自己扫描undo log了
How it could be?
A clear and concise description of what you want to happen. You can explain more about input of the feature, and output of it.
Other related information
Add any other context or screenshots about the feature request here.
问题1.我们看下
问题2. IN会按确切顺序锁定行，避免出现顺序问题导致互锁后的死锁问题
问题3.为什么不接入prometheus然后通过Grafana 配置报警？
问题3.看tc代码registry中并不会记录某个全局事务回滚失败了多少次。全局事物没结束的情况下，如果别人对全局事务中锁住的记录进行了修改（未加glbalLock或者globalTransaction的场景），全局事务发起回滚，比对镜像内容不一致就会无限重试（默认），而且永远都不能成功，这种场景其实是需要人工介入的。这个目前有参数能配置告警出来吗
未来会通过控制台做好回滚次数上限,超出后需要登录seata控制台进行手动下发
ibrsph3r2#
Why you need it?
Is your feature request related to a problem? Please describe in details
生成afterImage的时候用的 (id，...) in (1,...)，在用sharding时无法路由到对应的表，造成所有库所有表都扫描了。影响性能
另tc建议加个定时扫描针对rollback失败超过多少次或者多少时间的接入下通知（丁丁或者啥），也不用每个业务方自己扫描undo log了
How it could be?
A clear and concise description of what you want to happen. You can explain more about input of the feature, and output of it.
Other related information
Add any other context or screenshots about the feature request here.
问题1.我们看下
问题2. IN会按确切顺序锁定行，避免出现顺序问题导致互锁后的死锁问题
问题3.为什么不接入prometheus然后通过Grafana 配置报警？
ecfsfe2w3#
if (!RootContext.requireGlobalLock() && BranchType.AT != RootContext.getBranchType()) { // Just work as original statement return statementCallback.execute(statementProxy.getTargetStatement(), args); }ocebsuys4#
https://github.com/seata/seata/blob/8f62e9cf0854d9e315cc554d41c782f5e6bc588d/rm-datasource/src/main/java/io/seata/rm/datasource/exec/ExecuteTemplate.java#L75
nsc4cvqm5#
if (!RootContext.requireGlobalLock() && BranchType.AT != RootContext.getBranchType()) { // Just work as original statement return statementCallback.execute(statementProxy.getTargetStatement(), args); }我的场景是给方法打上了GlobalLock的注解，RootContext.requireGlobalLock()是ture，并不会直接执行目标语句，而是生成了对应的UpdateExecute去执行了，UpdateExecute会在beforeImage中先selectForUpdate，在afterImage中又会根据beforeImage的内容查询获取修改后的内容，如果只是单纯不分库分表性能损耗也还好，但是如果分库分表了，他的查询语句又没有带上我的分库键，就会导致所有库所有表都查一遍。单纯打globalLock的情况下也不会生成undoLog的，所以其实beforeImage和afterImage的逻辑没必要执行
a8jjtwal6#
Why you need it?
Is your feature request related to a problem? Please describe in details
生成afterImage的时候用的 (id，...) in (1,...)，在用sharding时无法路由到对应的表，造成所有库所有表都扫描了。影响性能
另tc建议加个定时扫描针对rollback失败超过多少次或者多少时间的接入下通知（丁丁或者啥），也不用每个业务方自己扫描undo log了
How it could be?
A clear and concise description of what you want to happen. You can explain more about input of the feature, and output of it.
Other related information
Add any other context or screenshots about the feature request here.
问题1.我们看下
问题2. IN会按确切顺序锁定行，避免出现顺序问题导致互锁后的死锁问题
问题3.为什么不接入prometheus然后通过Grafana 配置报警？
问题3.看tc代码registry中并不会记录某个全局事务回滚失败了多少次。全局事物没结束的情况下，如果别人对全局事务中锁住的记录进行了修改（未加glbalLock或者globalTransaction的场景），全局事务发起回滚，比对镜像内容不一致就会无限重试（默认），而且永远都不能成功，这种场景其实是需要人工介入的。这个目前有参数能配置告警出来吗