目前 globalsession 的生命周期相关方法，与每个模式完全耦合在一起，这可能会出现一种情况：在全局事务结束后，调用end方法清楚全局事务资源时，如果是纯TCC模式也会调用锁清除逻辑。
因此，还需要考虑正常结束清除资源的逻辑，需要区分是否是纯TCC正常结束资源，如果是这种情况，则不需要清除资源，后续事务结束这块逻辑，我认为需要再抽象一层出来，每个模式都有自己的事务结束逻辑，这样就不会像现在在方法里面添加更多的if slse 的面向过程的编码方式。
我来说说我的看法，欢迎社区的大家参与讨论 目前事务的remove update 皆是通过globalsession去处理，endXXX等行为又是通过SessionHelper去调用处理，而changestatus又是由globalsession调用，globalsession是否应该由某个类如SessionHelper完全控制，且在SessionHelper中分为以下几种情况 1.每个事务模式应该有自己的clean，end 2.每个store下又应该有不同的end clean，包括unlock这些的行为 3.sessionmanager不再是一个listener的角色，而是类似mapper的角色，他应该直接将globalsession被修改后的结果持久化到本地磁盘/db/redis
在我这个pr里面正好贯穿了整个流程 https://github.com/seata/seata/pull/4383 ，当时就发现整个流程长且不够清晰。 其中比较乱的一个点是sessionManager和globalSession很多方法是类似等效，但不完全相同。另一个点是listener的职责。 我的建议是以下几点 1.globalsession不再提供changestatus这种操作 2.主干逻辑的写内存（globalsession）和持久化（sessionmanager）收敛到一个类的方法，可以是sessionhelper（这个类的角色职责对应rm的defaultResourceManager，在调用abstractResourceManager之前的主流程处理） 3.listener这个角色改造成和主流程无关，只做类似订阅变化的，比如某个特定模式相关的事情。 4.listener通过上述改造后是否可以去掉addlistener这种操作，用spi直接扫描即可？
我觉得listener 应该是一个 tcc listener at listener saga listener xa listener，对应的listener收到了如removebranch，就应该是对应的listener去调用sessionmanager做持久化处理，在无特殊模式的特殊护理时，应该listener有一个default方法，统一走一个调用sessionmanager的持久化处理，sessionmanager应该被独立出来，而不是既是一个持久层处理器，又是一个listener
1、Session存储属于主逻辑，不应该放在listener里；listener应该是一些旁路的扩展处理 2、GlobalSession就是一个POJO类，不应该去实现Lifecycle类，应该抽象出单独类全权负责Session生命周期的管理，有一个模板生命周期管理抽象类，不同的事务模式下根据逻辑的不同可以有相应的实现 3、监控打点通知处理点混乱，应该跟随Session的生命周期管理 4、SessionHelper定位不清晰，有的是公共工具方法，有的又是Session生命周期管理相关的 5、SessionManager中的方法都加入了taskName的判断，初看代码觉得莫名其妙，逻辑不清晰；如果只是为了方便查不同状态的Session，抽出不同状态的公共方法就好了，没必要通过别名的方式去定义SessionManager