justabug

optimize : reorganize the usage of task session manager(add/remove/find/update)

1

- [ ] I have registered the PR [changes](https://github.com/seata/seata/tree/develop/changes). ### Ⅰ. Describe what this PR did 重新整理SessionHolder里面的几个sessionManager，统一把对globalsession的增删查改都改为使用root manager。 现在还没正式改好代码，我把需要改的地方全部todo标注出来，后面改的时候每改一个就删一个todo注释。以下是梳理情况： 1. 查询（把有非root的地方改成root.findxx ,真正要改的地方只有3个,已经用红色圈出来） allsessions本来在不同的manager有自带不同的查询条件，但现在看起来已经被改造过了     2. 删除（把有非root的地方改成root.removexx ,真正要改的地方只有4个,已经用红色圈出来）...

## Why you need it? Is your feature request related to a problem? Please describe in details 目前SessionHolder里面带有4个session manager（root/async_commit/retry_commit/retry_rollback），这4个manager在很多场景下都等价，所以root以外的manager大多被滥用，造成代码难读和维护困难，在进行新功能开发时也无法收敛到同一处，例如: 以下两个写法是等价的（都是移除全局事务） ``` SessionHolder.getRetryCommittingSessionManager().removeGlobalSession(committingSession); SessionHolder.getRootSessionManager().removeGlobalSession(committingSession); ``` 但以下两个写法是不一定等价的（在db/redis模式下用root是真正的新增，而用其他的则是更新，这和方法名称表达也不一致。） ``` SessionHolder.getRetryCommittingSessionManager().addGlobalSession(session); SessionHolder.getRootSessionManager().addGlobalSession(session); ``` 另一个问题是在globalsession里面addSessionLifecycleListener，可能会让globalsession持有多个manager，在某些操作（比如changestatus的时候，就会出现调用多次manager的情况，如果他们行为一致，那就是多余操作，如果他们行为不一致，那后果可能更严重）...

[WIP]optimize : change transaction state thread-safe in db/redis mode

1

### Ⅰ. Describe what this PR did 更新globalstatus的时候采用线程安全的方式，阻止预期状态不匹配的操作继续执行。 目前的思路是：rollback和commit都用乐观锁方式去更新globalsession的status，更新成功的会往下执行。没有更新成功的会遇到异常而中断。 传参expected status方式使用threadlocal 以下两个pr优化了之后，这个pr可以简化 https://github.com/seata/seata/pull/4858 https://github.com/seata/seata/pull/4881 ### Ⅱ. Does this pull request fix one issue? fixes https://github.com/seata/seata/issues/4372 ### Ⅲ. Why don't you...

optimize : remove unwatch() in redis updateGlobalTransactionDO

1

- [ ] I have registered the PR [changes](https://github.com/seata/seata/tree/develop/changes). ### Ⅰ. Describe what this PR did redis模式里的updateGlobalTransactionDOreturn或者throw之前的 unwatch是没有必要的，因为在close的时候都会重置状态。 这个pr做了两件事 1. 去掉没有必要的unwatch（如果觉得有风险可以先改成finally里面统一unwatch） 2. 优化代码格式 ### Ⅱ. Does this pull request fix...

## Why you need it? Is your feature request related to a problem? Please describe in details redis模式里的updateGlobalTransactionDO在处理redis事务时使用了watch，但是使用unwatch的写法不统一，有些在抛出异常或者return之前执行了unwatch，有些则没有。需要搞清楚unwatch是不是必须的，然后保持写法一致 ## How it could be? A clear and concise description of what...

optimize : tccfence log table deleted should be optimized

1

- [ ] I have registered the PR [changes](https://github.com/seata/seata/tree/develop/changes). ### Ⅰ. Describe what this PR did 1. 先查出可以清理的数据 2. 按索引删除数据 3. 给delete加上limit ### Ⅱ. Does this pull request fix one...

bugfix: fix rollback event repeated and some event status not correct

1

- [ ] I have registered the PR [changes](https://github.com/seata/seata/tree/develop/changes). ### Ⅰ. Describe what this PR did 解决https://github.com/seata/seata/issues/4531 提到的问题 1 是handleRetryCommitting超时后直接发了event，但没有endCommit ---- 改造成endCommitFail ---- （https://github.com/seata/seata/pull/4551 改造之后仍然有这个问题） 2 是endRollbackFailed自带了postTcSessionEndEvent()，下面还再发一次，事件重复了 ----去掉外层的event，保留新方法里面的event ---- （https://github.com/seata/seata/pull/4551...

bugfix : check if table meta cache should be refreshed in AT mode

1

- [ ] I have registered the PR [changes](https://github.com/seata/seata/tree/develop/changes). ### Ⅰ. Describe what this PR did AT模式下，在构造record的时候会遍历resultset并从tablemeta里获取表结构。如果数据库表中新建了一个字段，就会报空指针。 fix思路是先把原本的buildRecords改为private方法，并在检测到null时抛出一个固定的异常，新方法在捕捉到异常后会进行tablemeta刷新(靠StatementProxy提供connection、dbtype、resourceid) 现在用双锁来控制并发，内存标识在tableMeta里面（保证同key只会刷新一次，不管是不是并发） AbstractUndoExecutor里没有StatementProxy，但undo过程如果meta都不对应的话肯定是回滚不了，已忽略 目前刷新TableMetaCacheFactory缓存问题不大，但各个类都自己又搞了变量来缓存tablemeta，已经把这种变量去掉，改成直接从cachefactory取，性能可能有轻微下降，有其他好建议可以告诉我 ### Ⅱ. Does this pull request fix one issue?...

- [ ] I have registered the PR [changes](https://github.com/seata/seata/tree/develop/changes). ### Ⅰ. Describe what this PR did 解决获取all session时 因为limit导致数据不全，而可能导致不能及时处理超时session的问题。 目前的思路有几个，但是各有各问题，想在这里跟大家讨论一下。 1. 单独编写readTimeoutSession方法，用类似分页的方式循环往下获取，并筛选过期的session，直至数量达到logQueryLimit。（参考现在提交的RedisTransactionStoreManager） 这样的问题是：多次获取的过程中，session也在变化，这样分页依然会有数据会查不到 2. 单独编写readTimeoutSession方法，如果过期的session不达到logQueryLimit但还有很多session没被查出来（也就是issue提到的情况），就等待10ms再获取一遍，就这样重试5次。（参考现在提交的DataBaseTransactionStoreManager） 这样的问题是：就这样等10ms有点暴力，而且这样等了之后下次查询的结果还不一定有多少变化。 3. 改写readSession(GlobalStatus[] statuses, boolean...