After Seata is integrated into distributed transactions, how can Seata AT processes not be executed in a single data source scenario (TransactionType.LOCAL is sufficient)

[kutouziUk]

version
Seata: 2.0.0
ShardingJDBC: 5.3.2

question
After Seata is integrated into distributed transactions, adding @transactional(rollbackFor = Except.class) on the business methods AT this point will execute the Seata AT process to execute the transaction. However, there are many scenarios where a single data source is being manipulated and TransactionType. LOCAL is sufficient. Is there a solution that only executes the Seata AT Spring transactions process in the case of multiple data sources, and that @transactional(rollbackFor = Exception.class) executes normal Spring transactions in the case of a single data source?

[linghengqian]

• One of the issues involved here is that after enabling Seata integration, ShardingSphere actually hosts the real data source of Seata proxy. To bypass Seata client, you have to use Hikaricp or other database connection pools to create a ShardingSphere logical datasource again, which is back to the problem of registering multiple datasource Spring beans. This sounds like something that has been explained in the Spring documentation.

• If the seata client doesn't expose a more usable java api, it's hard to say what can be done here.

[kutouziUk]

• One of the issues involved here is that after enabling Seata integration, ShardingSphere actually hosts the real data source of Seata proxy. To bypass Seata client, you have to use Hikaricp or other database connection pools to create a ShardingSphere logical datasource again, which is back to the problem of registering multiple datasource Spring beans. This sounds like something that has been explained in the Spring documentation.这里涉及的一个问题是，启用 Seata 集成后，ShardingSphere 实际上托管了 Seata 代理的真实数据源。要绕过 Seata 客户端，必须再次使用 Hikaricp 或其他数据库连接池创建 ShardingSphere 逻辑数据源，这又回到了注册多个数据源 Spring bean 的问题。这听起来像是 Spring 文档中已经解释过的内容。
• If the seata client doesn't expose a more usable java api, it's hard to say what can be done here.如果 seata 客户端没有公开更有用的 java api，那么很难说这里可以做什么。

I understand what you're saying, most of the time the methods in the service operate on a single data source and don't involve distributed transactions at this point, in a few cases it involves distributed transactions because of the use of shard tables or remote calls. When it does not involve distributed transactions, it is still brokered by Seata, requiring global transaction ids, registering branch transactions, etc., which do not actually need to be carried out. If you can use this annotation like @GlobalTransactional, then use distributed transactions. Using @transactional continues to execute local transactions. I think it's more of an optimization point

[linghengqian]

• If you mean the org.apache.seata.spring.annotation.GlobalTransactional annotation, that annotation is actually only processed by org.apache.seata.spring.annotation.GlobalTransactionScanner, and the related classes are actually only valid for Spring Framework. The metadata scanning of shardingsphere actually bypasses all spring-related things.

• I am not sure how 建议：关于 seata-integration-tx-api 下的 GlobalTransactional 注解命名问题 incubator-seata#6951 will be resolved in the end. The logic of re-implementing org.apache.seata.spring.annotation.GlobalTransactionScanner on the shardingsphere side seems a bit strange. The public java api of shardingsphere is basically disguised as a normal java datasource.

[kutouziUk]

• If you mean the org.apache.seata.spring.annotation.GlobalTransactional annotation, that annotation is actually only processed by org.apache.seata.spring.annotation.GlobalTransactionScanner, and the related classes are actually only valid for Spring Framework. The metadata scanning of shardingsphere actually bypasses all spring-related things.如果你指的是 org.apache.seata.spring.annotation.GlobalTransactional Comments，那么该 Comments 实际上只由 org.apache.seata.spring.annotation.GlobalTransactionScanner 处理，并且相关类实际上仅对 Spring Framework 有效。shardingsphere 的元数据扫描实际上绕过了所有与 Spring 相关的事情。
• I am not sure how 建议：关于 seata-integration-tx-api 下的 GlobalTransactional 注解命名问题 incubator-seata#6951 will be resolved in the end. The logic of re-implementing org.apache.seata.spring.annotation.GlobalTransactionScanner on the shardingsphere side seems a bit strange. The public java api of shardingsphere is basically disguised as a normal java datasource.我不确定最终会如何 建议：关于 seata-integration-tx-api 下的 GlobalTransactional 注解命名问题 incubator-seata#6951 解决。在 shardingsphere 端重新实现 org.apache.seata.spring.annotation.GlobalTransactionScanner 的逻辑似乎有点奇怪。shardingsphere 的公共 java api 基本都是伪装成普通的 java 数据源。

@GlobalTransactional is just an example and is not intended to implement its logic on the shardingjdbc side. What I want to say is that after configuring TRANSACTION=BASE, all data sources are brokered globally by Seata. In the case of a single data source, the full Seata AT process could not have been executed because using external components would have introduced more risk, and it would have been better to commit the transaction more simply and quickly, without the need to involve Seata's two-stage commit. Seata's two-phase commit is performed only when distributed transactions are involved. I just want to consult whether there is such a solution in shardingjdbc, but I don't know. If not, I will use the current global proxy.

[linghengqian]

• I would say no at the moment.

• But I guess what you want to do is to change org.apache.shardingsphere.transaction.base.seata.at.SeataATShardingSphereTransactionManager to also save the map of the real datasource that is not proxied by org.apache.seata.rm.datasource.DataSourceProxy. Then use system properties to dynamically switch whether to use the seata client to open transactions? This may require some external testing.

[kutouziUk]

• I would say no at the moment.我现在会说不。
• But I guess what you want to do is to change org.apache.shardingsphere.transaction.base.seata.at.SeataATShardingSphereTransactionManager to also save the map of the real datasource that is not proxied by org.apache.seata.rm.datasource.DataSourceProxy. Then use system properties to dynamically switch whether to use the seata client to open transactions? This may require some external testing.但我想你想做的是改变 org.apache.shardingsphere.transaction.base.seata.at.SeataATShardingSphereTransactionManager 以保存真实数据源的映射，该映射不是由 代理的 org.apache.seata.rm.datasource.DataSourceProxy 。然后利用系统属性动态切换是否使用 seata 客户端来开启交易？这可能需要一些外部测试。

What you say makes sense, I tried to implement it before, but I know some of shardingjdbc source code, not completely familiar with it, so it did not succeed. Now I'd rewrite the SeataATShardingSphereTransactionManager to read seata configuration from the NACOS , rather than seata.conf. I try to implement this from SeataATShardingSphereTransactionManager logic. Thank you for your answer

[linghengqian]

• The design of shardingsphere only reading seata.conf can be traced back to shardingsphere 4.x. At that time, I was not a shardingsphere committer. I would say that this file appeared very abruptly. But there is indeed no issue on the shardingsphere side to propose a new configuration solution to replace seata.conf.

[kutouziUk]

• The design of shardingsphere only reading seata.conf can be traced back to shardingsphere 4.x. At that time, I was not a shardingsphere committer. I would say that this file appeared very abruptly. But there is indeed no issue on the shardingsphere side to propose a new configuration solution to replace seata.conf.

Yes, ZooKeeper is now supported in version 5.x as a registry, and it's even better for seata.conf to read the configuration from ZooKeeper or another configuration center like NACOS

[linghengqian]

After Seata is integrated into distributed transactions, adding @transactional(rollbackFor = Except.class) on the business methods AT this point will execute the Seata AT process to execute the transaction. However, there are many scenarios where a single data source is being manipulated and TransactionType. LOCAL is sufficient. Is there a solution that only executes the Seata AT Spring transactions process in the case of multiple data sources, and that @transactional(rollbackFor = Exception.class) executes normal Spring transactions in the case of a single data source?

• It's hard to say that I know why the current issue needs to be kept open. Unless you intend to propose a new design solution to the current issue. As you can see, the unit test of seata client by shardingsphere is a bit weird.