- I have searched the issues of this repository and believe that this is not a duplicate.
Ⅰ. Issue Description
name属性是由用户侧来保证唯一的,并且最终将会被当作资源id进行注册。但是即使有两个相同的名称,应用启动时也不会报告此错误,这将导致 TCCResourceManager 中 tccResourceCache 中的相同键被覆盖
name is guaranteed to be unique by the user side and will eventually be registered as a resource id. However, even if there are two identical names, this error will not be reported at startup, which would result in an overwrite of the same key in the tccResourceCache in the TCCResourceManager
Ⅱ. Describe what happened
If there is an exception, please attach the exception trace:
Just paste your stack trace here!
Ⅲ. Describe what you expected to happen
- 为什么不由我们替用户生成一个唯一的tcc资源名称,比如通过注解所在方法的method.toGenericString()方法,而不是让用户自己去在注解上指定和维护 why don't we generate a unique tcc resource name for the user, e.g. through the method.toGenericString() method of the method where the annotation is located, instead of letting the user specify and maintain it in the annotation themselves
- 在注册资源时增加判断,如果有相同名称的资源,通过抛出异常的方式告知用户是不是会比较好 add judgment when registering resources, if there is a resource with the same name, inform the user by throwing an exception is not better
Ⅳ. How to reproduce it (as minimally and precisely as possible)
- xxx
- xxx
- xxx
Minimal yet complete reproducer code (or URL to code):
Ⅴ. Anything else we need to know?
Ⅵ. Environment:
- JDK version(e.g.
java -version
): - Seata client/server version:
- Database version:
- OS(e.g.
uname -a
): - Others:
9条答案
按热度按时间aamkag611#
ds97pgxw2#
如何生成一个唯一id在业务应用或者tc重启的时候还能记录在案,并且正常下发二阶段指令?
如何确认相同资源名的类,一定不能使用?比如子类和父类的关系?
How to generate a unique ID that can be recorded and used even after a business application or TC restart, ensuring the ability to issue two-phase commands?
How to ensure that classes with the same resource name cannot be used, especially in the relationship between subclasses and parent classes?
通过接口名 + 方法名 + 方法参数的方式,比如io.seata.samples.tcc.springboot.dubbo.action.Test.method1(int),资源id指定后就保持不变,本质上都是静态的,不会影响重启相关的逻辑 By means of interface name + method name + method parameters, such as io.seata.samples.tcc.springboot.dubbo.action.Test.method1(int), the resource id is specified to remain unchanged, and the change in the generation method will not affect the restart of the relevant logic
TCC资源有父子类的情况吗?能麻烦讲一下场景吗 Is there a parent-child class scenario for TCC resources? Can you please tell us about the scenario?
mqkwyuun3#
如何生成一个唯一id在业务应用或者tc重启的时候还能记录在案,并且正常下发二阶段指令?
如何确认相同资源名的类,一定不能使用?比如子类和父类的关系?
How to generate a unique ID that can be recorded and used even after a business application or TC restart, ensuring the ability to issue two-phase commands?
How to ensure that classes with the same resource name cannot be used, especially in the relationship between subclasses and parent classes?
通过接口名 + 方法名 + 方法参数的方式,比如io.seata.samples.tcc.springboot.dubbo.action.Test.method1(int),资源id指定后就保持不变,本质上都是静态的,不会影响重启相关的逻辑 By means of interface name + method name + method parameters, such as io.seata.samples.tcc.springboot.dubbo.action.Test.method1(int), the resource id is specified to remain unchanged, and the change in the generation method will not affect the restart of the relevant logic
TCC资源有父子类的情况吗?能麻烦讲一下场景吗 Is there a parent-child class scenario for TCC resources? Can you please tell us about the scenario?
1.全限定名+方法+参数确实应该是一个唯一的id Fully qualified name + method + parameter should indeed be a unique id
2.第二种我认为是有可能的情况 The second I think is a possible scenario
hk8txs484#
然后我认为存在一种兼容性问题,比如服务的更新,当旧服务的resourceid为a时,因为它进行了更新,此时他的resourceid就可能叫做b,此时如果tc进行二阶段下发就会找不到相应的rm
Then I think there is a kind of compatibility problem, for example, the update of the service, when the old service's resourceid is a, because it made an update, at this time his resourceid may be called b, at this time if tc makes a two-phase download will not be able to find the corresponding rm
uinbv5nw5#
然后我认为存在一种兼容性问题,比如服务的更新,当旧服务的resourceid为a时,因为它进行了更新,此时他的resourceid就可能叫做b,此时如果tc进行二阶段下发就会找不到相应的rm Then I think there is a kind of compatibility problem, for example, the update of the service, when the old service's resourceid is a, because it made an update, at this time his resourceid may be called b, at this time if tc makes a two-phase download will not be able to find the corresponding rm
由用户指定name的话,如果在他版本更新时更新了这个name,也会存在你说的问题。这块是不是可以做一个优雅下线处理,RM下线时要先断绝一切请求,这样就不会再有新的分支事务的注册了。然后等待所有在当前RM上通过branchRegister注册的分支事务所在的全局事务结束之后,对TC的ChannelManager#RM_CHANNELS进行deregister摘除当前节点的Channel,然后再进行下线。这样就可以保证TC不会请求到旧的RM,同时旧的RM在下线之前也把和RM有关的旧的全局事务都完成了
If the name is specified by the user, the problem you mentioned will also exist if the name is updated during his version update. Isn't it possible to do a graceful offline processing for this piece, where the RM goes offline by first disconnecting all requests so that no new branch transactions are registered. Then wait for all the branch transactions registered on the current RM via branchRegister to finish, then deregister the TC's ChannelManager#RM_CHANNELS to remove the current node's Channel, and then go offline again. This ensures that the TC does not request the old RM, and that the old RM completes all the old global transactions related to the RM before going offline
gkl3eglg6#
It is necessary to support customized resource identification, but it is not recommended to introduce additional service management costs. We cannot guarantee that every user can log off gracefully. If a user changes their fully qualified name, is there any way we can expose the risk to the user?
支持自定义的资源标识是有必要的,不是很建议引入额外的服务治理成本。我们不能保证每位用户都能做到优雅下线,如果用户更换了全限定名,我们有没有什么办法将风险暴露给用户?
sg24os4d7#
It is necessary to support customized resource identification, but it is not recommended to introduce additional service management costs. We cannot guarantee that every user can log off gracefully. If a user changes their fully qualified name, is there any way we can expose the risk to the user? 支持自定义的资源标识是有必要的,不是很建议引入额外的服务治理成本。我们不能保证每位用户都能做到优雅下线,如果用户更换了全限定名,我们有没有什么办法将风险暴露给用户?
oyjwcjzk8#
优雅线下是一种解决方案,弄新的resourceid格式兼容两者也是一个方案。前者有不确定性,后者的可靠性更高,但是方案更为复杂。
Elegant offline is one solution, getting a new resourceid format compatible with both is also a solution. The former has uncertainty, the latter is more reliable, but the solution is more complex.
vatpfxk59#
If the user does not configure resource identification, I think it is acceptable to generate default rules; if the user configures it by himself, just ensure that different applications do not affect each other (remember that previous versions will affect each other, not sure if it is completely fixed) .
In fact, this is similar to the Mapping configuration in SpringMVC.
如果用户没有配置资源标识,给予默认规则生成我认为是可以接受的;如果用户有自行配置,保证不同应用之间互不影响即可(记得之前版本是会互相影响的,不确定是否完全fix)。
其实这个和SpringMVC中的Mapping配置类似。