seata Globalsession 生命周期管理优化

e0uiprwp  于 4个月前  发布在  其他
关注(0)|答案(5)|浏览(44)

Why you need it?

目前 globalsession 的生命周期相关方法,与每个模式完全耦合在一起,这可能会出现一种情况:在全局事务结束后,调用end方法清楚全局事务资源时,如果是纯TCC模式也会调用锁清除逻辑。

How it could be?

因此,还需要考虑正常结束清除资源的逻辑,需要区分是否是纯TCC正常结束资源,如果是这种情况,则不需要清除资源,后续事务结束这块逻辑,我认为需要再抽象一层出来,每个模式都有自己的事务结束逻辑,这样就不会像现在在方法里面添加更多的if slse 的面向过程的编码方式。

Add any other context or screenshots about the feature request here.

ca1c2owp

ca1c2owp1#

let me try,please assign it to me

lvjbypge

lvjbypge2#

我来说说我的看法,欢迎社区的大家参与讨论
目前事务的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

sc4hvdpw

sc4hvdpw3#

在我这个pr里面正好贯穿了整个流程 #4383 ,当时就发现整个流程长且不够清晰。
其中比较乱的一个点是sessionManager和globalSession很多方法是类似等效,但不完全相同。另一个点是listener的职责。
我的建议是以下几点
1.globalsession不再提供changestatus这种操作
2.主干逻辑的写内存(globalsession)和持久化(sessionmanager)收敛到一个类的方法,可以是sessionhelper(这个类的角色职责对应rm的defaultResourceManager,在调用abstractResourceManager之前的主流程处理)
3.listener这个角色改造成和主流程无关,只做类似订阅变化的,比如某个特定模式相关的事情。
4.listener通过上述改造后是否可以去掉addlistener这种操作,用spi直接扫描即可?

mjqavswn

mjqavswn4#

我觉得listener 应该是一个 tcc listener at listener saga listener xa listener,对应的listener收到了如removebranch,就应该是对应的listener去调用sessionmanager做持久化处理,在无特殊模式的特殊护理时,应该listener有一个default方法,统一走一个调用sessionmanager的持久化处理,sessionmanager应该被独立出来,而不是既是一个持久层处理器,又是一个listener

2w3rbyxf

2w3rbyxf5#

1、Session存储属于主逻辑,不应该放在listener里;listener应该是一些旁路的扩展处理
2、GlobalSession就是一个POJO类,不应该去实现Lifecycle类,应该抽象出单独类全权负责Session生命周期的管理,有一个模板生命周期管理抽象类,不同的事务模式下根据逻辑的不同可以有相应的实现
3、监控打点通知处理点混乱,应该跟随Session的生命周期管理
4、SessionHelper定位不清晰,有的是公共工具方法,有的又是Session生命周期管理相关的
5、SessionManager中的方法都加入了taskName的判断,初看代码觉得莫名其妙,逻辑不清晰;如果只是为了方便查不同状态的Session,抽出不同状态的公共方法就好了,没必要通过别名的方式去定义SessionManager

相关问题