linghengqian commented on issue #30242: URL: https://github.com/apache/shardingsphere/issues/30242#issuecomment-1960839245
> project a use SeataATShardingTransactionManager,can other project use GlobalTransactionScanner? - The answer is yes, as long as you avoid using both ShardingSphere's Seata-AT integration and Seata's Java API within the same project. It sounds like `project A` is using ShardingSphere's Seata-AT integration, and then `project B` is using Seata's TCC mode. The connection between them is only possible through `project A`'s `registry.conf` and `project B`'s `application.yml`, because Seata's TCC mode must use things within the Spring Framework. - When `project A` uses ShardingSphere's Seata AT integration, I will not recommend that you configure the equivalent content of `registry.conf` in `application.yaml`, because this is currently an **undefined behavior**. You are welcome to submit in the master branch of ShardingSphere unit test. > when running projectA.test2(),projectb.test3 throw exception.can SeataATShardingTransactionManager notify project A to rollback? - This issue may not seem like something that can be handled on the ShardingSphere side at first glance, as it definitely depends on the Seata Server. You can take a look at https://github.com/apache/shardingsphere/blob/a4632ab6140698b3e4950df4f66169caa8c65bb9/kernel/transaction/type/base/seata-at/src/main/java/org/apache/shardingsphere/transaction/base/seata/at/SeataATShardingSphereTransactionManager.java. - Determining whether a piece of code is in an open transaction state depends on the return value of `io.seata.core.context.RootContext.getXID()`. This requires quoting documentation for https://seata.apache.org/zh-cn/docs/user/api/#1-%E8%BF%9C%E7%A8%8B%E8%B0%83%E7%94%A8%E4%BA%8B%E5%8A%A1%E4%B8%8A%E4%B8%8B%E6%96%87%E7%9A%84%E4%BC%A0%E6%92%AD . For the most part I will say that Seata's English documentation seems not quite ready yet and is weird to read. > 1. 远程调用事务上下文的传播 > 远程调用前获取当前 XID： > String xid = RootContext.getXID(); > 远程调用过程把 XID 也传递到服务提供方，在执行服务提供方的业务逻辑前，把 XID 绑定到当前应用的运行时： > RootContext.bind(rpcXid); > 2. 事务的暂停和恢复 > 在一个全局事务中，如果需要某些业务逻辑不在全局事务的管辖范围内，则在调用前，把 XID 解绑： > String unbindXid = RootContext.unbind(); > 待相关业务逻辑执行完成，再把 XID 绑定回去，即可实现全局事务的恢复： > RootContext.bind(unbindXid); - Classification discussion. - 1. This means that if you are using ShardingSphere JDBC, `project A` may not be notified when `project B` throws an exception, but I am not sure if two projects use the same **transaction group** of Seata , whether the Seata Server side will initiate notifications to other Seata Clients in the **transaction group**. - 2. If the Seata AT mode is integrated with a ShardingSphere Proxy instance, and `project A` and `project B` initiate transaction requests to this ShardingSphere Proxy instance through local transactions in Java or Python, it seems that this problem should not exist. - Anyway, at least I am not an Apache Seata Committer. I would rather suggest that you open an issue at https://github.com/apache/incubator-seata with documentation issues. I'm not even an original contributor to the current integration implementation of Seata AT mode, I just wrote the corresponding integration tests for it under GraalVM Native Image. -- 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]
