Project: ShardingSphere (App Definition and Development / Database)
File: seata.en.md

+++ title = "Seata Transaction" weight = 7 +++ Apache ShardingSphere provides BASE transactions that integrate the Seata implementation. All references to Seata integration in this article refer to Seata AT mode. Introduce Maven dependencies and exclude the outdated Maven dependencies of `org.antlr:antlr4-runtime:4.8` in `io.seata:seata-all`. ```xml <project> <dependencies> <dependency> <groupId>org.apache.shardingsphere</groupId> <artifactId>shardingsphere-jdbc</artifactId> <version>${shardingsphere.version}</version> </dependency> <dependency> <groupId>org.apache.shardingsphere</groupId> <artifactId>shardingsphere-transaction-base-seata-at</artifactId> <version>${shardingsphere.version}</version> </dependency> <dependency> <groupId>io.seata</groupId> <artifactId>seata-all</artifactId> <version>2.0.0</version> <exclusions> <exclusion> <groupId>org.antlr</groupId> <artifactId>antlr4-runtime</artifactId> </exclusion> </exclusions> </dependency> </dependencies> </project> ``` Start Seata Server Create the log table Add the Seata configuration Follow the steps in or https://hub.docker.com/r/seataio/seata-server , download and start the Seata server. Create the `undo_log` table in each shard database instance (take MySQL as an example). The content of SQL is subject to the corresponding database in https://github.com/apache/incubator-seata/tree/v2.0.0/script/client/at/db . ```sql CREATE TABLE IF NOT EXISTS `undo_log` ( `branch_id` BIGINT NOT NULL COMMENT 'branch transaction id', `xid` VARCHAR(128) NOT NULL COMMENT 'global transaction id', `context` VARCHAR(128) NOT NULL COMMENT 'undo_log context,such as serialization', `rollback_info` LONGBLOB NOT NULL COMMENT 'rollback info', `log_status` INT(11) NOT NULL COMMENT '0:normal status,1:defense status', `log_created` DATETIME(6) NOT NULL COMMENT 'create datetime', `log_modified` DATETIME(6) NOT NULL COMMENT 'modify datetime', UNIQUE KEY `uxundolog` (`xid`, `branch_id`) ) ENGINE = InnoDB AUTO_INCREMENT = 1 DEFAULT CHARSET = utf8mb4 COMMENT ='AT transaction mode undo table'; ALTER TABLE `undolog` ADD INDEX `ixlogcreated` (`logcreated`); ``` Add the `seata.conf` file to the root directory of the classpath. The configuration file format refers to the of `io.seata.config.FileConfiguration`. There are four properties in `seata.conf`, `shardingsphere.transaction.seata.at.enable`, when this value is `true`, ShardingSphere's Seata AT integration is enabled, there is a default value of `true` `shardingsphere.transaction.seata.tx.timeout`, global transaction timeout in SECONDS, there is a default value of `60` `client.application.id`, apply the only primary key `client.transaction.service.group`, the transaction group it belongs to, there is a default value of `default` A fully configured `seata.conf` is as follows, ```conf shardingsphere.transaction.seata.at.enable = true shardingsphere.transaction.seata.tx.timeout = 60 client { application.id = example transaction.service.group = defaulttxgroup } ``` Modify the `file.conf` and `registry.conf` files of Seata as required. ShardingSphere's Seata integration does not support isolation levels. ShardingSphere's Seata integration places the obtained Seata global transaction into the thread's local variables. And `org.apache.seata.spring.annotation.GlobalTransactionScanner` uses Dynamic Proxy to enhance the method. This means that users should never use the `io.seata:seata-all` Java annotation for ShardingSphere's DataSource. That is, when using ShardingSphere's Seata integration, users should avoid using the Java API of

For ShardingSphere data source, discuss 6 situations, Manually obtain the `java.sql.Connection` instance created from the ShardingSphere data source, and manually calling the `setAutoCommit()`, `commit()` and `rollback()` methods is allowed. Using the Jakarta EE 8 `javax.transaction.Transactional` annotation on the function is allowed. Using Jakarta EE 9/10s `jakarta.transaction.Transactional` annotation on functions is allowed. Using Spring Frameworks `org.springframework.transaction.annotation.Transactional` annotation on functions is allowed. Using the `io.seata.spring.annotation.GlobalTransactional` annotation on the function is not allowed. Manually create `io.seata.tm.api.GlobalTransaction` instance from `io.seata.tm.api.GlobalTransactionContext`, calling the `begin()`, `commit()` and `rollback()` methods of an `io.seata.tm.api.GlobalTransaction` instance is not allowed. For Seata Server 2.0.0, Seata Server does not pass the return value of `io.seata.core.context.RootContext.getXID()` to all connected Seata Client instances of the same transaction group, Reference https://seata.apache.org/docs/user/api/ . This requires discussing two situations, In the scenario of using ShardingSphere JDBC, transaction scenarios across multiple microservices need to consider using `io.seata.core.context.RootContext.getXID()` in the context of the starting microservice to obtain the Seata XID and then pass it to the ending microservice through RPC, and call `io.seata.core.context.RootContext.bind(rpcXid)` in the business function of the endpoint microservice. In the scenario of using ShardingSphere Proxy, Multiple microservices operate local transactions against the logical dataSource of ShardingSphere Proxy, this will be converted into distributed transaction operations on the server side of ShardingSphere Proxy, there are no additional Seata XIDs to consider. In the actual scenario of using Spring Boot OSS, `com.alibaba.cloud:spring-cloud-starter-alibaba-seata` and `io.seata:seata-spring-boot-starter` are often introduced transitively by other Maven dependencies. In order to avoid transaction conflicts, users need to manually turn off Seata's auto-config class. And set the `seata.enable-auto-data-source-proxy` property to `false` in the Spring Boot OSS configuration file. A possible dependency is as follows. ```xml <project> <dependencies> <dependency> <groupId>org.apache.shardingsphere</groupId> <artifactId>shardingsphere-jdbc</artifactId> <version>${shardingsphere.version}</version> </dependency> <dependency> <groupId>org.apache.shardingsphere</groupId> <artifactId>shardingsphere-transaction-base-seata-at</artifactId> <version>${shardingsphere.version}</version> </dependency> <dependency> <groupId>io.seata</groupId> <artifactId>seata-spring-boot-starter</artifactId> <version>2.0.0</version> <exclusions> <exclusion> <groupId>org.antlr</groupId> <artifactId>antlr4-runtime</artifactId> </exclusion> </exclusions> </dependency> </dependencies> </project> ``` The corresponding Spring Boot OSS bootstrap class may be as follows. ```java import io.seata.spring.boot.autoconfigure.SeataAutoConfiguration; import org.springframework.boot.SpringApplication; import org.springframework.boot.autoconfigure.SpringBootApplication; @SpringBootApplication(exclude = SeataAutoConfiguration.class) public class ExampleApplication { public static void main(String[] args) { SpringApplication.run(ShardingsphereSeataSpringBootTestApplication.class, args); } } ``` The corresponding `application.yml` under the classpath needs to contain the following configuration. In this case, the equivalent configuration of Seata's `registry.conf` defined in `application.yaml` of Spring Boot OSS may not be valid. This depends on the Seata Client. When a downstream project uses the Maven module `org.apache.shardingsphere:shardingsphere-transaction-base-seata-at`, users are always encouraged to configure Seata Client using `registry.conf`. ```yaml seata: enable-auto-data-source-proxy: false ```