Does Shardingsphere version 5.4.0 support seata transaction tcc mode?

[Python-IBM]

Question

For English only, other languages will not accept.

Before asking a question, make sure you have:

• Googled your question.
• Searched open and closed GitHub issues.
• Read documentation: ShardingSphere Doc.

Please pay attention on issues you submitted, because we maybe need more details.
If no response anymore and we cannot reproduce it on current information, we will close it.

Does Shardingsphere version 5.4.0 support seata transaction tcc mode?

[github-actions[bot]]

There hasn't been any activity on this issue recently, and in order to prioritize active issues, it will be marked as stale.

[linghengqian]

• I completed clarification in Bump io.seata:seata-all for testing to 2.0.0 #30146 that when using org.apache.shardingsphere:shardingsphere-transaction-base-seata-at you should not actually use any Seata Java API. This includes but is not limited to the use of TCC related classes as follows,
  • io.seata.rm.tcc.api.TwoPhaseBusinessAction
  • io.seata.rm.tcc.api.BusinessActionContextParameter
  • io.seata.rm.tcc.api.LocalTCC
• Using TCC-related Java classes is actually behavior that is not defined by unit tests, which may require a new module. I assume you have related ideas for adding unit tests?
• This will most likely require some changes on Seata's side, see TCC模式怎么通过纯api方式使用呢？ incubator-seata#4828.

[github-actions[bot]]

There hasn't been any activity on this issue recently, and in order to prioritize active issues, it will be marked as stale.

[funky-eyes]

Hi @linghengqian,

I believe TCC and Seata (AT) do not conflict with each other. The databases involved in TCC should not be proxied by Seata's DataSourceProxy. If DataSourceProxy is used, it requires adding @GlobalLock + @transactional annotations and using select ... for update statements to first retrieve data before updating.

Based on different business scenarios and transactional patterns used, different sets of data tables are employed. Therefore, I see no inherent conflict between the two. TCC belongs to the business layer of transactional patterns, whereas AT (Seata) pertains to transactional patterns at the data layer. Given that ShardingSphere is also considered middleware for the data layer, I do not see any points of conflict between TCC and ShardingSphere.

[linghengqian]

The databases involved in TCC should not be proxied by Seata's DataSourceProxy. If DataSourceProxy is used, it requires adding @GlobalLock + @transactional annotations and using select ... for update statements to first retrieve data before updating.

• @funky-eyes Hi, I noticed that TCC模式怎么通过纯api方式使用呢？ incubator-seata#4828 has been closed, but https://github.com/apache/incubator-seata-samples/tree/master/tcc-sample does not have a unit test that avoids using io.seata.spring.annotation.GlobalTransactionScanner. So from my personal perspective, this seems to still be partially in conflict with the existing situation of ShardingSphere.
• On the ShardingSphere side, all real data sources are converted to io.seata.rm.datasource.DataSourceProxy inside ShardingSphere. This will not have an impact when using io.seata:seata-all, but when using io.seata:seata-spring-boot-starter, ShardingSphere actually needs to set seata.enable-auto-data-source-proxy=false in Spring Boot's application.yml and other configuration files to avoid multiple layers of proxies for real data sources. Once seata.enable-auto-data-source-proxy=false is set, it seems that there is no way to define the data source used by Seata TCC. In this case, Seata TCC can only act on business functions called without data source. Refer to https://shardingsphere.apache.org/document/current/cn/user-manual/shardingsphere-jdbc/special-api/transaction/seata/ .
• Or did I misunderstand the seata document in https://seata.apache.org/zh-cn/docs/user/mode/tcc ? To let Seata TCC know the data source after setting seata.enable-auto-data-source-proxy=false, I only need to create or call a javax.sql.DataSource instance/spring bean in the business function of TCC? But even so, the @io.seata.spring.annotation.GlobalTransactional annotation still seems useless in scenarios such as Quarkus, Micronaut Framework, Helidon, etc., because io.seata.spring.annotation.GlobalTransactionScanner only targets scenarios where Spring Framework is on the classpath.

[funky-eyes]

Apologies for the inconvenience caused by our previous documentation not highlighting the usage of pure API. We have updated the documentation last night, please refer to https://seata.apache.org/docs/user/api for tutorials and usage.
In summary, Seata can ultimately identify instances annotated with @io.seata.spring.annotation.GlobalTransactional and proxy them via ProxyUtil.createProxy. It can also identify instances annotated with @TwoPhaseBusinessAction + @LocalTCC and proxy them.

[linghengqian]

• @funky-eyes Thanks for the clarification, I've opened Fixes the incorrect description of Seata TCC Mode in the doc #32144 to update the documentation.

[linghengqian]

• @funky-eyes Thanks for the clarification, I've opened Fixes the incorrect description of Seata TCC Mode in the doc #32144 to update the documentation.

• I hope I understand it correctly, but when using io.seata.integration.tx.api.util.ProxyUtil, the io.seata.spring.annotation.GlobalTransactional annotation still seems to be meaningless? Because the distributed transaction in TCC mode is enabled by io.seata.integration.tx.api.util.ProxyUtil.

[funky-eyes]

@GlobalTransactional still holds significance; however, in version 2.0, @GlobalTransactional and @TwoPhaseBusinessAction cannot be used together on the same method. This is because in version 2.0, detecting one annotation will ignore the other, resulting in the dynamic proxy of the ignored annotation not being applied. This issue has been addressed in version 2.1 (not yet released). When @GlobalTransactional is present on a class or method, after proxying with ProxyUtil and invoking the corresponding method on the proxy class, the global transaction is automatically initiated. This approach simplifies the process considerably compared to previous usage of GlobalTransactionContext.

[linghengqian]

• Thanks for the clarification.