apache / incubator-seata

:fire: Seata is an easy-to-use, high-performance, open source distributed transaction solution.
https://seata.apache.org/
Apache License 2.0
25.25k stars 8.77k forks source link

saga模式下加载DefaultResourceManager的resourceManagers 出现org.apache 和 io.seata紊乱? #6563

Closed bobbyz007 closed 4 months ago

bobbyz007 commented 4 months ago

Ⅰ. Issue Description

saga模式下加载DefaultResourceManager的initResourceManagers()方法中,EnhancedServiceLoader会默认以兼容模式同时加载org.apache和io.seata下的SataResourceManager, 也就是SAGA指向两个Manager,但添加到resourceManagers中被覆盖了只添加io.seata下的对象,导致org.apache和io.seata混乱。

protected void initResourceManagers() {
        //init all resource managers
        List<ResourceManager> allResourceManagers = EnhancedServiceLoader.loadAll(ResourceManager.class);
        if (CollectionUtils.isNotEmpty(allResourceManagers)) {
            for (ResourceManager rm : allResourceManagers) {
                resourceManagers.put(rm.getBranchType(), rm);
            }
        }
    }

Ⅲ. Describe what you expected to happen

当前代码兼容模式默认都是true,或者由用户指定,如果用户都是使用org.apache包,则compatible兼容设置为false,避免在使用org.apache下的包还会引用到io.seata下的对象

funky-eyes commented 4 months ago

这个应该不是bug,是特意而为,为了向下兼容特地以ioseata包为主,如果ioseata包下没有对应的实现才会加载到org.apache.seata包下的实现。如果你不想有io seata相关的依赖,可以不选择引入seata-all,自行引入对应的module依赖即可 This shouldn't be considered a bug; it is intentional. In order to maintain backward compatibility, the main focus is on the io.seata package. If there is no corresponding implementation under the io.seata package, then the implementation will be loaded from the org.apache.seata package. If you prefer not to have dependencies related to io.seata, you can choose not to import seata-all and instead manually import the corresponding module dependencies.

bobbyz007 commented 4 months ago

我觉得考虑向下兼容的前提是不能影响新版本的使用吧,为了向下兼容来牺牲新版本引入seata-all(某些情况下的问题),也不合理啊。 不知道为啥要在同一份代码中搞这种兼容,通过不同版本区分也行或类似common-lang/common-lang3这种区分就很清晰啊。

这个应该不是bug,是特意而为,为了向下兼容特地以ioseata包为主,如果ioseata包下没有对应的实现才会加载到org.apache.seata包下的实现。如果你不想有io seata相关的依赖,可以不选择引入seata-all,自行引入对应的module依赖即可 This shouldn't be considered a bug; it is intentional. In order to maintain backward compatibility, the main focus is on the io.seata package. If there is no corresponding implementation under the io.seata package, then the implementation will be loaded from the org.apache.seata package. If you prefer not to have dependencies related to io.seata, you can choose not to import seata-all and instead manually import the corresponding module dependencies.

funky-eyes commented 4 months ago

你说的影响使用是指什么?另外common-lang/common-lang3 这种难道让社区维护两个版本?这严重增加了历史用户迁移成本和社区维护成本 What do you mean by affecting usage? Also, are you suggesting that the community should maintain two versions like common-lang/common-lang3? This would significantly increase the migration cost for historical users and the maintenance cost for the community.

bobbyz007 commented 4 months ago

当依赖seata-all时,问题就是用户代码引入ora.apache新版本的类,最终却加载出了io.seata.saga.rm.SagaResourceManager, 而不是org.apache.seata.saga.rm.SagaResourceManager。

比如分两个版本,主要特性应该就是都在org.apache下开发, io.seata就修改合入下bug,最终就不维护了。 我看到现在其实就是在一份代码库中维护了两种逻辑,代码感觉更复杂啊。 以EnhancedServiceLoader为例, 里面很多方法都带个尾巴参数 boolean includeCompatible去做if判断。 这种if多了,开发自己都搞蒙了。这只是这一个类,其他类暂时不清楚

你说的影响使用是指什么?另外common-lang/common-lang3 这种难道让社区维护两个版本?这严重增加了历史用户迁移成本和社区维护成本 What do you mean by affecting usage? Also, are you suggesting that the community should maintain two versions like common-lang/common-lang3? This would significantly increase the migration cost for historical users and the maintenance cost for the community.

bobbyz007 commented 4 months ago

社区维护成本不好说。 用户成本没啥啊, 想用新版本的就是apache, 想用老版本的就用ioseata。 不像现在看着引入了apache,哪知道里面还有ioseata的代码

你说的影响使用是指什么?另外common-lang/common-lang3 这种难道让社区维护两个版本?这严重增加了历史用户迁移成本和社区维护成本 What do you mean by affecting usage? Also, are you suggesting that the community should maintain two versions like common-lang/common-lang3? This would significantly increase the migration cost for historical users and the maintenance cost for the community.

funky-eyes commented 4 months ago

社区维护成本不好说。 用户成本没啥啊, 想用新版本的就是apache, 想用老版本的就用ioseata。 不像现在看着引入了apache,哪知道里面还有ioseata的代码

你说的影响使用是指什么?另外common-lang/common-lang3 这种难道让社区维护两个版本?这严重增加了历史用户迁移成本和社区维护成本 What do you mean by affecting usage? Also, are you suggesting that the community should maintain two versions like common-lang/common-lang3? This would significantly increase the migration cost for historical users and the maintenance cost for the community.

有io seata的代码对你产生了什么影响?你认为用户成本没啥,是你认为。建议你看看dubbo社区如何做向alibaba dubbo进行兼容的。