kutouziUk commented on issue #34556: URL: https://github.com/apache/shardingsphere/issues/34556#issuecomment-2633102922
> * 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 a distributed transaction at this point, in a few cases it involves a distributed transaction because of the use of a table or remote call. 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 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: notifications-unsubscr...@shardingsphere.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
