linghengqian commented on issue #29712:
URL: 
https://github.com/apache/shardingsphere/issues/29712#issuecomment-1959554577

   @songhanlin 
   - I tested the following content at 
https://github.com/linghengqian/shardingsphere-seata-spring-boot-test . Most of 
the content comes directly from nativeTest on the ShardingSphere side.
     - Snapshot version of Apache ShardingSphere 5.5.0
     - Seata Server 2.0 and Seata Spring Boot 2.0
     - Spring Boot 3.2.2
     - Three independent Postgresql Server 16.2 instances
     - GraalVM CE For JDK21
   - Unit testing is perfectly fine, you just need to completely ignore Seata's 
Java API. All configurations for Seata Client need to be completed in 
`registry.conf`.
   ```shell
   sdk install java 21.0.2-graalce
   sdk use java 21.0.2-graalce
   
   git clone [email protected]:apache/shardingsphere.git
   cd ./shardingsphere/
   git reset --hard de192a30c9460bb94385c2a88e766025b211f906
   ./mvnw clean install -Prelease -T1C -DskipTests -Djacoco.skip=true 
-Dcheckstyle.skip=true -Drat.skip=true -Dmaven.javadoc.skip=true
   
   cd ../
   
   git clone 
[email protected]:linghengqian/shardingsphere-seata-spring-boot-test.git
   cd ./shardingsphere-seata-spring-boot-test/
   ./mvnw -e -T1C clean test
   ```
   - You need to turn off Seata's auto-configuration class, like 
`@SpringBootApplication(exclude = 
io.seata.spring.boot.autoconfigure.SeataAutoConfiguration.class)`. You also 
need to set `seata.enable-auto-data-source-proxy` to `false` in 
`application.yaml`.
   - For transactional consistency across multiple microservices, seriously, if 
you run `org.apache.shardingsphere:shardingsphere-transaction-base-seata-at` on 
a ShardingSphere Proxy,  There is no reason why content obtained from the 
`io.seata.core.context.RootContext.getXID()` should conflict.
   - For ShardingSphere JDBC, the current implementation appears to only ensure 
transaction consistency across threads of a single microservice. I haven't read 
how Seata handles transaction groups, but it seems that if the Seata Server can 
be connected normally, the processing of the transaction group depends more on 
the Seata side, and the ShardingSphere side cannot get the required content at 
all, which results in that it can only be The decision is left to Seata.


-- 
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: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]

Reply via email to