shardingsphere-jdbc 5.4.0 AT transaction rollback not taking effect #29712

Python-IBM · 2024-01-13T01:57:07Z

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 · 2024-01-20T08:55:30Z

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

lemonade-water · 2024-01-27T10:02:09Z

I had the same problem，Is there any way?

songhanlin · 2024-02-04T07:49:50Z

+1

linghengqian · 2024-02-16T16:05:50Z

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.

songhanlin · 2024-02-18T09:49:00Z

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 · 2024-02-18T10:00:34Z

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 · 2024-02-22T12:43:14Z

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 · 2024-02-22T14:22:30Z

@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 · 2024-02-22T14:24:25Z

@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 · 2024-02-23T11:49:28Z

According to the discussion results of used example【sharding--jdbc--cluster-zookeeper--base-seata】，but don't rollback #30242 , I will submit a new document PR to describe the integration of Seata in more detail.

linghengqian mentioned this issue Feb 16, 2024

Bump io.seata:seata-all for testing to 2.0.0 #30146

Merged

6 tasks

linghengqian added the type: duplicate label Feb 16, 2024

zhaojinchao95 closed this as completed in #30146 Feb 17, 2024

linghengqian self-assigned this Feb 17, 2024

linghengqian reopened this Feb 18, 2024

linghengqian added feature: transaction type: bug and removed type: duplicate labels Feb 18, 2024

linghengqian added status: need more info and removed type: bug labels Feb 22, 2024

linghengqian added the in: document label Feb 22, 2024

linghengqian mentioned this issue Feb 22, 2024

used example【sharding--jdbc--cluster-zookeeper--base-seata】，but don't rollback #30242

Closed

linghengqian mentioned this issue Feb 26, 2024

Updates documentation for restrictions on Seata’s Spring Boot Starter #30304

Merged

6 tasks

RaigorJiang closed this as completed in #30304 Feb 26, 2024

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

shardingsphere-jdbc 5.4.0 AT transaction rollback not taking effect #29712

shardingsphere-jdbc 5.4.0 AT transaction rollback not taking effect #29712

Python-IBM commented Jan 13, 2024 •

edited

Loading

doveylovey commented Jan 20, 2024

lemonade-water commented Jan 27, 2024

songhanlin commented Feb 4, 2024

linghengqian commented Feb 16, 2024

songhanlin commented Feb 18, 2024

linghengqian commented Feb 18, 2024

linghengqian commented Feb 22, 2024

linghengqian commented Feb 22, 2024 •

edited

Loading

linghengqian commented Feb 22, 2024

linghengqian commented Feb 23, 2024

shardingsphere-jdbc 5.4.0 AT transaction rollback not taking effect #29712

shardingsphere-jdbc 5.4.0 AT transaction rollback not taking effect #29712

Comments

Python-IBM commented Jan 13, 2024 • edited Loading

Bug Report

Which version of ShardingSphere did you use?

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

Expected behavior

Actual behavior

Reason analyze (If you can)

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

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

doveylovey commented Jan 20, 2024

lemonade-water commented Jan 27, 2024

songhanlin commented Feb 4, 2024

linghengqian commented Feb 16, 2024

songhanlin commented Feb 18, 2024

linghengqian commented Feb 18, 2024

linghengqian commented Feb 22, 2024

linghengqian commented Feb 22, 2024 • edited Loading

linghengqian commented Feb 22, 2024

linghengqian commented Feb 23, 2024

Python-IBM commented Jan 13, 2024 •

edited

Loading

linghengqian commented Feb 22, 2024 •

edited

Loading