fix dead lock in multi DB when using batchUpdate(#31038)

[H-Jason]

Fixes #31038.

Changes proposed in this pull request:

---

Before committing this PR, I'm sure that I have checked the following options:

• My code follows the code of conduct of this project.
• I have self-reviewed the commit code.
• I have (or in comment I request) added corresponding labels for the pull request.
• I have passed maven check locally : ./mvnw clean install -B -T1C -Dmaven.javadoc.skip -Dmaven.jacoco.skip -e.
• I have made corresponding changes to the documentation.
• I have added corresponding unit tests for my changes.

[linghengqian]

• You can wait for Fixes nativeTest failure under GraalVM Native Image due to class information changes #31320 to be merged and then rebase to the master branch. Failure of nativeTest is expected and requires the fix of Fixes nativeTest failure under GraalVM Native Image due to class information changes #31320 .

[H-Jason]

• You can wait for Fixes nativeTest failure under GraalVM Native Image due to class information changes #31320 to be merged and then rebase to the master branch. Failure of nativeTest is expected and requires the fix of Fixes nativeTest failure under GraalVM Native Image due to class information changes #31320 .

[H-Jason]

• You can wait for Fixes nativeTest failure under GraalVM Native Image due to class information changes #31320 to be merged and then rebase to the master branch. Failure of nativeTest is expected and requires the fix of Fixes nativeTest failure under GraalVM Native Image due to class information changes #31320 .

I have rebased the master branch

[linghengqian]

• You can wait for Fixes nativeTest failure under GraalVM Native Image due to class information changes #31320 to be merged and then rebase to the master branch. Failure of nativeTest is expected and requires the fix of Fixes nativeTest failure under GraalVM Native Image due to class information changes #31320 .

I have rebased the master branch

• But why do you need to turn off PR?

[H-Jason]

• You can wait for Fixes nativeTest failure under GraalVM Native Image due to class information changes #31320 to be merged and then rebase to the master branch. Failure of nativeTest is expected and requires the fix of Fixes nativeTest failure under GraalVM Native Image due to class information changes #31320 .

I have rebased the master branch

* But why do you need to turn off PR?

I am sorry,just misoperation

[linghengqian]

• The PR did not pass the code formatting validation. You can execute first ./mvnw spotless:apply -Pcheck -T1C. Then execute ./mvnw checkstyle:check -Pcheck -T1C to manually adjust to repair the CI.

[H-Jason]

• The PR did not pass the code formatting validation. You can execute first ./mvnw spotless:apply -Pcheck -T1C. Then execute ./mvnw checkstyle:check -Pcheck -T1C to manually adjust to repair the CI.

done

[linghengqian]

• You need to change the org.apache.shardingsphere.test.natived.jdbc.commons.TestShardingService#processSuccessInClickHouse(). Reference https://github.com/apache/shardingsphere/actions/runs/9387875307/job/25852084140?pr=31118#step:4:53356 .

Failures (1):
  JUnit Jupiter:ClickHouseTest:assertShardingInLocalTransactions()
    MethodSource [className = 'org.apache.shardingsphere.test.natived.jdbc.databases.ClickHouseTest', methodName = 'assertShardingInLocalTransactions', methodParameterTypes = '']
    => java.lang.AssertionError: 
Expected: <[1, 1, 1, 1, 1, 0, 0, 0, 0, 0]>
     but: was <[0, 0, 0, 0, 0, 1, 1, 1, 1, 1]>
       org.hamcrest.MatcherAssert.assertThat(MatcherAssert.java:20)
       org.hamcrest.MatcherAssert.assertThat(MatcherAssert.java:8)
       org.apache.shardingsphere.test.natived.jdbc.commons.TestShardingService.processSuccessInClickHouse(TestShardingService.java:100)
       org.apache.shardingsphere.test.natived.jdbc.databases.ClickHouseTest.assertShardingInLocalTransactions(ClickHouseTest.java:47)
       java.base@21.0.2/java.lang.reflect.Method.invoke(Method.java:580)
       java.base@21.0.2/java.util.ArrayList.forEach(ArrayList.java:1596)
       java.base@21.0.2/java.util.ArrayList.forEach(ArrayList.java:1596)

[H-Jason]

• You need to change the org.apache.shardingsphere.test.natived.jdbc.commons.TestShardingService#processSuccessInClickHouse(). Reference https://github.com/apache/shardingsphere/actions/runs/9387875307/job/25852084140?pr=31118#step:4:53356 .

Failures (1):
  JUnit Jupiter:ClickHouseTest:assertShardingInLocalTransactions()
    MethodSource [className = 'org.apache.shardingsphere.test.natived.jdbc.databases.ClickHouseTest', methodName = 'assertShardingInLocalTransactions', methodParameterTypes = '']
    => java.lang.AssertionError: 
Expected: <[1, 1, 1, 1, 1, 0, 0, 0, 0, 0]>
     but: was <[0, 0, 0, 0, 0, 1, 1, 1, 1, 1]>
       org.hamcrest.MatcherAssert.assertThat(MatcherAssert.java:20)
       org.hamcrest.MatcherAssert.assertThat(MatcherAssert.java:8)
       org.apache.shardingsphere.test.natived.jdbc.commons.TestShardingService.processSuccessInClickHouse(TestShardingService.java:100)
       org.apache.shardingsphere.test.natived.jdbc.databases.ClickHouseTest.assertShardingInLocalTransactions(ClickHouseTest.java:47)
       java.base@21.0.2/java.lang.reflect.Method.invoke(Method.java:580)
       java.base@21.0.2/java.util.ArrayList.forEach(ArrayList.java:1596)
       java.base@21.0.2/java.util.ArrayList.forEach(ArrayList.java:1596)

done

[linghengqian]

• This PR indeed explains some phenomena that have existed before and does affect some integration tests. From my perspective, there doesn't seem to be any significant issue with the current PR at this point. I'll await the completion of the CI process.

[H-Jason]

• This PR indeed explains some phenomena that have existed before and does affect some integration tests. From my perspective, there doesn't seem to be any significant issue with the current PR at this point. I'll await the completion of the CI process.

Thank you for your recognition.