linghengqian commented on issue #7837: URL: https://github.com/apache/incubator-seata/issues/7837#issuecomment-3789897836
As a ShardingSphere committer, I offer two approaches from the ShardingSphere JDBC perspective regarding `org.apache.shardingsphere:shardingsphere-transaction-base-seata-at`. Of course, I don't rule out the possibility of better handling methods on the Seata side. 1. One approach is to create two ShardingSphere logical databases: one using `transaction.defaultType=BASE` and `transaction.providerType=Seata`, and the other using `transaction.defaultType=LOCAL`. In fact, the local transaction for the logical database is equivalent to the distributed transaction for the real database. 2. If you'd like to test the branch at https://github.com/apache/shardingsphere/pull/37778 , you can dynamically modify the transaction model of a single logical database. Moreover, this can indeed largely guarantee the safety of cross-thread transactions, unless there is a physical power outage. ```java import com.zaxxer.hikari.HikariConfig; import com.zaxxer.hikari.HikariDataSource; import java.sql.Connection; import java.sql.SQLException; import java.sql.Statement; public class ExampleUtils { void test() throws SQLException { HikariConfig config = new HikariConfig(); config.setJdbcUrl("jdbc:shardingsphere:classpath:demo.yaml"); config.setDriverClassName("org.apache.shardingsphere.driver.ShardingSphereDriver"); try (HikariDataSource dataSource = new HikariDataSource(config); Connection connection = dataSource.getConnection(); Statement statement = connection.createStatement()) { statement.execute(""" alter transaction rule( default="LOCAL", type(name="") ) """); statement.execute("INSERT INTO t_order (user_id, order_type, address_id, status) VALUES (1, 1, 1, 'INSERT_TEST')"); statement.execute(""" alter transaction rule( default="BASE", type(name="Seata") ) """); statement.execute("INSERT INTO t_order (user_id, order_type, address_id, status) VALUES (2, 2, 2, 'INSERT_TEST')"); } } } ``` - I suspect the second method is closer to what you're looking for, as it introduces something like https://github.com/baomidou/dynamic-datasource , but without a Java API, only SQL. Furthermore, I wouldn't encourage you to use ShardingSphere JDBC's internal Java API, which undergoes significant changes with each version. https://github.com/apache/shardingsphere/pull/37778 is just a preceding PR in another large group of PRs. -- 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] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
