shardingsphere-jdbc 5.4.0 AT transaction rollback not taking effect

[Python-IBM]

Bug Report

For English only, other languages will not accept.

Before report a bug, make sure you have:

• 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.

Please answer these questions before submitting your issue. Thanks!

Which version of ShardingSphere did you use?

5.4.0

Which project did you use? ShardingSphere-JDBC or ShardingSphere-Proxy?

ShardingSphere-JDBC

Expected behavior

Server order calls the server account method, but the server order method encounters an exception. The server account method updates data normally. The server account' transactions can be rolled back normally in AT mode.

Actual behavior

Server order calls the server account method, but the server order method encounters an exception. The server account method updates data normally.The server account' transactions cannot be rolled back normally in AT mode.

Reason analyze (If you can)

Steps to reproduce the behavior, such as: SQL to execute, sharding rule configuration, when exception occur etc.

1. sharding rule configuration （1）server account transaction: defaultType: BASE providerType: Seata

（2）server order transaction: defaultType: BASE providerType: Seata

（3）server account sql log 2024-01-13T09:41:41.640+08:00 INFO 25804 --- [samplesAccount] [erverWorker-3-2] o.a.d.r.t.netty4.NettyServerHandler : [DUBBO] The connection of /192.168.1.103:56658 -> /192.168.1.103:20880 is established., dubbo version: 3.2.10, current host: 192.168.1.103 2024-01-13T09:41:46.064+08:00 INFO 25804 --- [samplesAccount] [:20880-thread-5] c.d.a.service.impl.TAccountServiceImpl : Account Service ... xid: 192.168.1.103:8091:171614677748609245 2024-01-13T09:41:46.086+08:00 INFO 25804 --- [samplesAccount] [:20880-thread-5] ShardingSphere-SQL : Logic SQL: SELECT id,user_id,amount,create_time FROM t_account WHERE (user_id = ?) 2024-01-13T09:41:46.086+08:00 INFO 25804 --- [samplesAccount] [:20880-thread-5] ShardingSphere-SQL : Actual SQL: ds1 ::: SELECT id,user_id,amount,create_time FROM t_account_1 WHERE (user_id = ?) ::: [3] 2024-01-13T09:41:46.097+08:00 INFO 25804 --- [samplesAccount] [:20880-thread-5] ShardingSphere-SQL : Logic SQL: update t_account set amount = amount-? where user_id = ? 2024-01-13T09:41:46.097+08:00 INFO 25804 --- [samplesAccount] [:20880-thread-5] ShardingSphere-SQL : Actual SQL: ds0 ::: update t_account_1 set amount = amount-? where user_id = ? ::: [5.0, 3] （4）server order sql log 01-13T09:41:46.052+08:00 INFO 25200 --- [samplesOrder] [:20881-thread-8] i.seata.tm.api.DefaultGlobalTransaction : Begin new global transaction [192.168.1.103:8091:171614677748609245] 2024-01-13T09:41:46.053+08:00 INFO 25200 --- [samplesOrder] [:20881-thread-8] c.d.o.service.impl.TOrderServiceImpl : Order Service xid: 192.168.1.103:8091:171614677748609245 2024-01-13T09:41:46.108+08:00 INFO 25200 --- [samplesOrder] [:20881-thread-8] i.seata.tm.api.DefaultGlobalTransaction : transaction 192.168.1.103:8091:171614677748609245 will be rollback 2024-01-13T09:41:46.128+08:00 INFO 25200 --- [samplesOrder] [:20881-thread-8] i.seata.tm.api.DefaultGlobalTransaction : transaction end, xid = 192.168.1.103:8091:171614677748609245 2024-01-13T09:41:46.128+08:00 INFO 25200 --- [samplesOrder] [:20881-thread-8] i.seata.tm.api.DefaultGlobalTransaction : [192.168.1.103:8091:171614677748609245] rollback status: Rollbacked java.lang.reflect.InvocationTargetException at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:568) at com.demo.account.service.impl.AccountServiceImpl.invoke(AccountServiceImpl.java:35) at com.demo.account.service.impl.AccountServiceImplDubboWrap0.invokeMethod(AccountServiceImpl.DubboWrap0.java) at org.apache.dubbo.rpc.proxy.javassist.JavassistProxyFactory$1.doInvoke(JavassistProxyFactory.java:89) at org.apache.dubbo.rpc.proxy.AbstractProxyInvoker.invoke(AbstractProxyInvoker.java:100) at org.apache.dubbo.config.invoker.DelegateProviderMetaDataInvoker.invoke(DelegateProviderMetaDataInvoker.java:55) at org.apache.dubbo.rpc.protocol.InvokerWrapper.invoke(InvokerWrapper.java:56) at org.apache.dubbo.rpc.filter.ClassLoaderCallbackFilter.invoke(ClassLoaderCallbackFilter.java:38) at org.apache.dubbo.rpc.cluster.filter.FilterChainBuilder$CopyOfFilterChainNode.invoke(FilterChainBuilder.java:349) at com.alibaba.dubbo.rpc.Invoker$CompatibleInvoker.invoke(Invoker.java:77) at io.seata.integration.dubbo.alibaba.AlibabaDubboTransactionPropagationFilter.invoke(AlibabaDubboTransactionPropagationFilter.java:45) at com.alibaba.dubbo.rpc.Filter.invoke(Filter.java:34) at org.apache.dubbo.rpc.cluster.filter.FilterChainBuilder$CopyOfFilterChainNode.invoke(FilterChainBuilder.java:349) at org.apache.dubbo.rpc.protocol.dubbo.filter.TraceFilter.invoke(TraceFilter.java:80) at org.apache.dubbo.rpc.cluster.filter.FilterChainBuilder$CopyOfFilterChainNode.invoke(FilterChainBuilder.java:349) at org.apache.dubbo.rpc.filter.TimeoutFilter.invoke(TimeoutFilter.java:45) at org.apache.dubbo.rpc.cluster.filter.FilterChainBuilder$CopyOfFilterChainNode.invoke(FilterChainBuilder.java:349) at org.apache.dubbo.seata.SeataTransactionPropagationProviderFilter.invoke(SeataTransactionPropagationProviderFilter.java:66) at org.apache.dubbo.rpc.cluster.filter.FilterChainBuilder$CopyOfFilterChainNode.invoke(FilterChainBuilder.java:349) at org.apache.dubbo.monitor.support.MonitorFilter.invoke(MonitorFilter.java:108) at org.apache.dubbo.rpc.cluster.filter.FilterChainBuilder$CopyOfFilterChainNode.invoke(FilterChainBuilder.java:349) at org.apache.dubbo.rpc.filter.ExceptionFilter.invoke(ExceptionFilter.java:54) at org.apache.dubbo.rpc.cluster.filter.FilterChainBuilder$CopyOfFilterChainNode.invoke(FilterChainBuilder.java:349) at org.apache.dubbo.rpc.filter.AccessLogFilter.invoke(AccessLogFilter.java:120) at org.apache.dubbo.rpc.cluster.filter.FilterChainBuilder$CopyOfFilterChainNode.invoke(FilterChainBuilder.java:349) at org.apache.dubbo.metrics.observation.ObservationReceiverFilter.invoke(ObservationReceiverFilter.java:57) at org.apache.dubbo.rpc.cluster.filter.FilterChainBuilder$CopyOfFilterChainNode.invoke(FilterChainBuilder.java:349) at org.apache.dubbo.rpc.filter.GenericFilter.invoke(GenericFilter.java:222) at org.apache.dubbo.rpc.cluster.filter.FilterChainBuilder$CopyOfFilterChainNode.invoke(FilterChainBuilder.java:349) at org.apache.dubbo.rpc.filter.ClassLoaderFilter.invoke(ClassLoaderFilter.java:54) at org.apache.dubbo.rpc.cluster.filter.FilterChainBuilder$CopyOfFilterChainNode.invoke(FilterChainBuilder.java:349) at org.apache.dubbo.rpc.filter.EchoFilter.invoke(EchoFilter.java:41) at org.apache.dubbo.rpc.cluster.filter.FilterChainBuilder$CopyOfFilterChainNode.invoke(FilterChainBuilder.java:349) at org.apache.dubbo.metrics.filter.MetricsFilter.invoke(MetricsFilter.java:86) at org.apache.dubbo.metrics.filter.MetricsProviderFilter.invoke(MetricsProviderFilter.java:37) at org.apache.dubbo.rpc.cluster.filter.FilterChainBuilder$CopyOfFilterChainNode.invoke(FilterChainBuilder.java:349) at org.apache.dubbo.rpc.filter.ProfilerServerFilter.invoke(ProfilerServerFilter.java:66) at org.apache.dubbo.rpc.cluster.filter.FilterChainBuilder$CopyOfFilterChainNode.invoke(FilterChainBuilder.java:349) at org.apache.dubbo.rpc.filter.ContextFilter.invoke(ContextFilter.java:145) at org.apache.dubbo.rpc.cluster.filter.FilterChainBuilder$CopyOfFilterChainNode.invoke(FilterChainBuilder.java:349) at org.apache.dubbo.rpc.cluster.filter.FilterChainBuilder$CallbackRegistrationInvoker.invoke(FilterChainBuilder.java:197) at org.apache.dubbo.rpc.protocol.dubbo.DubboProtocol$1.reply(DubboProtocol.java:167) at org.apache.dubbo.remoting.exchange.support.header.HeaderExchangeHandler.handleRequest(HeaderExchangeHandler.java:110) at org.apache.dubbo.remoting.exchange.support.header.HeaderExchangeHandler.received(HeaderExchangeHandler.java:205) at org.apache.dubbo.remoting.transport.DecodeHandler.received(DecodeHandler.java:52) at org.apache.dubbo.remoting.transport.dispatcher.ChannelEventRunnable.run(ChannelEventRunnable.java:64) at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136) at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635) at org.apache.dubbo.common.threadlocal.InternalRunnable.run(InternalRunnable.java:39) at java.base/java.lang.Thread.run(Thread.java:842) Caused by: java.lang.RuntimeException: try to proceed invocation error at io.seata.spring.annotation.AdapterInvocationWrapper.proceed(AdapterInvocationWrapper.java:59) at io.seata.integration.tx.api.interceptor.handler.GlobalTransactionalInterceptorHandler$2.execute(GlobalTransactionalInterceptorHandler.java:200) at io.seata.tm.api.TransactionalTemplate.execute(TransactionalTemplate.java:128) at io.seata.integration.tx.api.interceptor.handler.GlobalTransactionalInterceptorHandler.handleGlobalTransaction(GlobalTransactionalInterceptorHandler.java:197) at io.seata.integration.tx.api.interceptor.handler.GlobalTransactionalInterceptorHandler.doInvoke(GlobalTransactionalInterceptorHandler.java:166) at io.seata.integration.tx.api.interceptor.handler.AbstractProxyInvocationHandler.invoke(AbstractProxyInvocationHandler.java:35) at io.seata.spring.annotation.AdapterSpringSeataInterceptor.invoke(AdapterSpringSeataInterceptor.java:45) at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:184) at org.springframework.aop.framework.CglibAopProxy$CglibMethodInvocation.proceed(CglibAopProxy.java:765) at org.springframework.aop.framework.CglibAopProxy$DynamicAdvisedInterceptor.intercept(CglibAopProxy.java:717) at com.demo.order.service.impl.TOrderServiceImpl$$SpringCGLIB$$0.createOrder() ... 53 more Caused by: java.lang.NullPointerException: Cannot invoke "com.demo.model.order.entity.TOrder.setCount(java.lang.Integer)" because "tOrder" is null at com.demo.order.service.impl.TOrderServiceImpl.createOrder(TOrderServiceImpl.java:52) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:568) at org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:352) at org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:196) at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:163) at org.springframework.aop.framework.CglibAopProxy$CglibMethodInvocation.proceed(CglibAopProxy.java:765) at io.seata.spring.annotation.AdapterInvocationWrapper.proceed(AdapterInvocationWrapper.java:57)

Example codes for reproduce this issue (such as a github link).

（1）server account code （2）server order code

[doveylovey]

I had the same problem, and it never worked out, you know?

[lemonade-water]

I had the same problem，Is there any way?

[songhanlin]

+1

[linghengqian]

• I believe this is essentially a duplicate of https://github.com/apache/shardingsphere/issues/22356#issuecomment-1948463141 , and the use of annotations within io.seata:seata-spring-boot-starter should be avoided, including io.seata.spring.annotation.GlobalTransactional.
• I believe this issue involves adjustments to the Spring Boot Starter side of Seata.

[songhanlin]

• I believe this is essentially a duplicate of SpringCloud+Seata1.5.2+ShardingSphereJDBC5.2.1 SeataATShardingSphereTransactionManager.commit throw null exception #22356 (comment) , and the use of annotations within io.seata:seata-spring-boot-starter should be avoided, including io.seata.spring.annotation.GlobalTransactional.
• I believe this issue involves adjustments to the Spring Boot Starter side of Seata.

我用新提交的文档说明里面的依赖跑不起来, 我主要用这俩

<dependency>
    <groupId>com.alibaba.cloud</groupId>
    <artifactId>spring-cloud-starter-alibaba-seata</artifactId>
    <version>2022.0.0.0</version>
</dependency>

<dependency>
    <groupId>org.apache.shardingsphere</groupId>
    <artifactId>shardingsphere-transaction-base-seata-at</artifactId>
    <version>5.4.1</version>
</dependency>

但是仍然有问题, 似乎单个服务没有问题, 多个服务之间没有事务组的概念, 每个服务都是单独的全局事务, 都会独自提交事务; 不知道这边有完整的demo吗? @linghengqian

[linghengqian]

• I believe this is essentially a duplicate of SpringCloud+Seata1.5.2+ShardingSphereJDBC5.2.1 SeataATShardingSphereTransactionManager.commit throw null exception #22356 (comment) , and the use of annotations within io.seata:seata-spring-boot-starter should be avoided, including io.seata.spring.annotation.GlobalTransactional.
• I believe this issue involves adjustments to the Spring Boot Starter side of Seata.

我用新提交的文档说明里面的依赖跑不起来, 我主要用这俩

<dependency>
    <groupId>com.alibaba.cloud</groupId>
    <artifactId>spring-cloud-starter-alibaba-seata</artifactId>
    <version>2022.0.0.0</version>
</dependency>

<dependency>
    <groupId>org.apache.shardingsphere</groupId>
    <artifactId>shardingsphere-transaction-base-seata-at</artifactId>
    <version>5.4.1</version>
</dependency>

但是仍然有问题, 似乎单个服务没有问题, 多个服务之间没有事务组的概念, 每个服务都是单独的全局事务, 都会独自提交事务; 不知道这边有完整的demo吗? @linghengqian

• This seems a bit difficult to verify, so let me modify the seata side of the example to test it. The problem involved here is that currently all unit tests assume that only a single transaction group is used.

[linghengqian]

• To be honest, it is difficult to see a similar counterpart in https://github.com/apache/incubator-seata-samples . The seata side also normally uses a single microservice for testing. I'm going to break out a set of unit tests from the existing nativeTest for GraalVM Native Image.

• Something like this is difficult to demonstrate in the example module of shardingsphere git because I'm not a freemarker expert. I'll use a separate git explanation.

[linghengqian]

@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 Starter 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.

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 that 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.

[linghengqian]

• @songhanlin If you have questions, can you open a new issue for discussion? The current issue describes another documentation issue and is not a place that should continue to be discussed.

[linghengqian]

• According to the discussion results of #30242 , I will submit a new document PR to describe the integration of Seata in more detail.