Why you need it?
Is your feature request related to a problem? Please describe in details
当tm端的channel与tc端断开时，很大可能是因为tm宕机了，如果tm宕机说明tm无法决议事务，但是调用链可能已经到了最后一步，假设这个tm调用了10个微服务，那么在AT下已经锁定了非常多的数据，而默认的timeoutrollback的时间是60秒，tm的宕机会导致数据被锁定60秒不可用，这是比较恶劣的
解决方案参考：
1.通过绑定channelInactive的事件处理，并需要增加开关，因为有可能由于网络问题误判，导致回滚了事务，所以默认开关应该是关闭的，不提前回滚全局事务
2.拥有提前rollback权限的是begin的那个tc，其余tc即便感知到tm断线，也不应该进行rollback，避免出现同时进行rollback或者其中一台tc与tm断开连接导致的误判，所以粒度可以控制在begin的tc上
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.
3条答案
按热度按时间axr492tv1#
plz assign it to me
7fhtutme2#
对于解决方案第2点，可在TC收到globalTransactionBegin后将xid存到内存来解决，但由于收到begin的tc和二阶段决议的tc不一定是同一台，若TM一直没断连，就会存在oom的风险，经讨论，现梳理出三种解决方案，欢迎大家一起讨论给出优化建议。
1.db和redis以及file加一个字段将globalsession和TM ip产生联系,在TC channel断开时,通过channel的ip去查相关begin的事务提前回滚 --db需要增加额外字段，存在向下兼容的风险；增加了该issue解决复杂度
2.使用guava的缓存 默认128大小,先进先出,channel断开后,去查这个128个xid的状态,如果是begin,将其回滚 - 存在一定漏回滚的全局事务，但先进先出且大小设置合理的情况下，后面begin的事务可能都还没完成事务处理，基本可控
3.begin和决议时的rpc走begin的tc,当begin的tcchannel找不到时,改用原来的负载均衡到其它tc去决议 这样内存里可以完成保持channel跟xid的关系,当事务进入二阶段时就可以从这个集合里删掉相关xid --存在向下兼容的风险，低版本客户端一样会导致TC出现oom
nimxete23#
是否可以复用 application_data 存放channel信息？ 或者在XID里面存上 channel 信息