TC下发回滚，执行xaRollback报错

[xiaoxiangyeyu0]

Check Ahead

• I have searched the issues of this repository and believe that this is not a duplicate.

• I am willing to try to fix this bug myself.

Ⅰ. Issue Description

TC下发回滚对应PG数据库是新连接的state为IDLE，在166行先xaEnd，PG驱动前置状态判断state不为ACTIVE会报错，导致一直回滚失败，mysql如果是新连接，驱动发送给数据库是命令是XA END 'xxx'，也会报错。
解决方案：
去掉166行的xaEnd调用，放到151行和152行之间，如果是旧连接，先调用xaEnd

Ⅱ. Describe what happened

No response

Ⅲ. Describe what you expected to happen

No response

Ⅳ. How to reproduce it (as minimally and precisely as possible)

No response

Ⅴ. Anything else we need to know?

No response

Ⅵ. Environment

No response

[funky-eyes]

#5034 This PR was closed because it received no reviews. The PR keeps the stage‑one connection open; during stage two, if the decision is to go to "end" at that point, no error will occur because it uses the existing (old) connection.

[xiaoxiangyeyu0]

使用旧的连接没有问题，这个PR没有合并的话，现在只有MYSQL8.0.29之前和MARIADB连接ShouldBeHeld，现在PG数据库情况下，TC下发的xaCommit和xaRollback是新连接，所以有这个问题。166行的代码是最近加的，调整判断xaBranchXid不为空时，说明是旧连接，执行xaEnd验证是没问题的。

[xiaoxiangyeyu0]

经过mysql5.7验证，151行和152行之间也不能调用xaEnd方法，因为一阶段执行close方法会调用XA END 'xxx'和XA PREPARE ‘xxx’，然后在cleanXABranchContext方法里面把xaEnded置为false，再次执行xaEnd就会报下面的错。
所以能不能直接把166行去掉，但我不知道当时做合并事务功能加上这一行的目的是什么？

[funky-eyes]

经过mysql5.7验证，151行和152行之间也不能调用xaEnd方法，因为一阶段执行close方法会调用XA END 'xxx'和XA PREPARE ‘xxx’，然后在cleanXABranchContext方法里面把xaEnded置为false，再次执行xaEnd就会报下面的错。 所以能不能直接把166行去掉，但我不知道当时做合并事务功能加上这一行的目的是什么？

我认为保留166行是为了提前阻断事务，假设事务还在运行中，还未执行close，但是已经start注册了这个分支事务，不进行end是无法成功rollback的，也就无法提前阻断这个事务的进行。而cleanXABranchContext说明事务已经结束，所以close的时候清除上下文是必要的。不过我认为如果held为true时，说明这个链接被持有到二阶段，xaEnded不应该被修改为false。然后在releaseIfNecessary的时候再进行xaEnded改为false。

I think keeping line 166 is meant to preemptively block the transaction. Suppose the transaction is still running and close has not yet been called, but the branch has already been registered by start — without performing end it cannot be rolled back successfully, so you cannot preemptively stop the transaction from proceeding. The cleanXABranchContext indicates the transaction has finished, so clearing the context on close is necessary. However, I believe that if held is true (meaning this connection is held through to the second phase), xaEnded should not be set to false there; xaEnded should be set to false later in releaseIfNecessary.

[xiaoxiangyeyu0]

调用org.apache.seata.rm.datasource.xa.ConnectionProxyXA.xaRollback(XAXid)方法一共是下面4个地方checkTimeout(Long)、rollback()、start()、xaRollback(String, long, String)

对于checkTimeout方法，是在close方法调用的，close方法调用checkTimeout前会调用end(int)方法，end调用xaEnd调用到xaResource.end(xaXid, flags);
对于rollback方法，调用xaRollback方法前，也会调用xaEnd调用到xaResource.end(xaXid, flags);
对于start方法，直接会调用到xaResource.end(this.xaBranchXid, XAResource.TMFAIL);

上面这3个方法都是close前会调用到的，都会提前end，xaResource.rollback(xaXid);就会成功。

对于xaRollback(String, long, String)是二阶段调用的，如果是新连接，直接xaResource.rollback就好，如果拿到旧连接，这个连接在一阶段肯定被end过了。

所以直接把166行去掉就好

[funky-eyes]

为什么拿到旧链接一定会是被end过的？假设connection.setautocommit(false) 开启事务，然后有一个耗时很长的sql，或者业务逻辑，此时TC触发这个全局事务的超时回滚，进行下发的该RM，从RM拿到被hold的连接进行rollback，由于没有end只会失败，怎么会成功呢？
Why would obtaining the old connection necessarily mean end() has already been called? Suppose you call connection.setAutoCommit(false) to start a transaction, and then a long-running SQL statement or business logic is running. If the TC triggers a global transaction timeout and issues a rollback to the RM, the RM will take the held connection and call rollback. Without calling end() first the rollback would fail — how could it possibly succeed?

[xiaoxiangyeyu0]

这种超时情况的rollback的确会失败。所以在166行调用xaEnd前，要判断xaActive为true才行。
不过我觉得能不能把xaEnded标志位去掉，在执行xaEnd方法里面，使用xaActive为true判断才调用xaResource.end，因为xaActive为true说明xaResource.start过