seata-all 1.6.1 at模式,在断点处等待会触发两次全局回滚的bug

rryofs0p  于 22天前  发布在  其他
关注(0)|答案(4)|浏览(13)

Ⅰ. Issue Description

使用seata-all 1.6.1作为客户端依赖,伪代码如下:

public class Test{

  private static String applicationId="abcd";
    private static String transactionServiceGroup="my_test_tx_group";
    static{
        TMClient.init(applicationId, transactionServiceGroup);
        RMClient.init(applicationId, transactionServiceGroup);
    }
    private static final TransactionalTemplate transactionalTempl = new TransactionalTemplate();

    public static void test() throws Throwable{
        try {
            transactionalTemplate.execute(new TransactionalExecutor() {
                @Override
                public Object execute() throws Throwable {

                    throw new RuntimeException();
                }

                @Override
                public TransactionInfo getTransactionInfo() {

                    TransactionInfo transactionInfo = new TransactionInfo();
                    transactionInfo.setTimeOut(180000);
                    transactionInfo.setName("default");
                    transactionInfo.setPropagation(Propagation.REQUIRED);

                    Set<RollbackRule> rollbackRules = new LinkedHashSet<>();
                    rollbackRules.add(new RollbackRule(Throwable.class));

                    transactionInfo.setRollbackRules(rollbackRules);
                    return transactionInfo;
                }
            });
        }catch (Throwable e){
            e.printStackTrace();
        }

        int i=0; //在此处添加断点,debug让程序跑到断点处停下来,会出现两次回滚 Rollback global transaction successfully

    }

    public static void main(String[] args) throws Throwable{
        test();
    }

}

上面图片里出现两次全局回滚,并且数据库global_table表里的相应的记录很长时间才删除!

registry.conf文件内如如下:

registry {
  # file 、nacos 、eureka、redis、zk
  type = "nacos"

  nacos {
      application="seata-server"
      serverAddr="192.168.137.199:8848"
      namespace=""
      cluster="default"
      group="SEATA_GROUP"
      username="nacos"
      password="nacos"
  }
}

config {
  # file、nacos 、apollo、zk
  type = "file"
  file {
    name = "file.conf"
  }
}

//file.conf文件内容如下

transport {
  # tcp udt unix-domain-socket
  type = "TCP"
  enableRmClientBatchSendRequest = true
  enableTmClientBatchSendRequest = true
  #NIO NATIVE
  server = "NIO"
  #enable heartbeat
  heartbeat = true
  #thread factory for netty
  threadFactory {
    bossThreadPrefix = "NettyBoss"
    workerThreadPrefix = "NettyServerNIOWorker"
    serverExecutorThread-prefix = "NettyServerBizHandler"
    shareBossWorker = false
    clientSelectorThreadPrefix = "NettyClientSelector"
    clientSelectorThreadSize = 1
    clientWorkerThreadPrefix = "NettyClientWorkerThread"
    # netty boss thread size,will not be used for UDT
    bossThreadSize = 1
    #auto default pin or 8
    workerThreadSize = "default"
  }
}
service {
  #vgroup->rgroup
  vgroupMapping.my_test_tx_group = "default"
  #only support single node
  #default.grouplist = "127.0.0.1:8091"
  #degrade current not support
  enableDegrade = false
  #disable
  disable = false
}

client {
   rm {
      asyncCommitBufferLimit = 10000
      lock {
        retryInterval = 10
        retryTimes = 1
        retryPolicyBranchRollbackOnConflict = true
      }
      reportRetryCount = 1
      tableMetaCheckEnable = false
      reportSuccessEnable = true
   }
   tm {
        defaultGlobalTransactionTimeout = 180000
        commitRetryCount = 1
        rollbackRetryCount = 1
   }

   undo {
      dataValidation = true
      logSerialization = "jackson"
      logTable = "undo_log"
   }
   log {
      exceptionRate = 100
   }
}
w41d8nur

w41d8nur1#

@ulwx Logs are printed in different threads, and the log time difference is greater than 2 minutes and 10 seconds, which is caused by the delay deletion mechanism.

v09wglhw

v09wglhw2#

@ulwx Logs are printed in different threads, and the log time difference is greater than 2 minutes and 10 seconds, which is caused by the delay deletion mechanism.

感觉还是有问题,我调试了很多次,发现还是触发两次回滚,第一次回滚成功后,global_table里全局记录没有删除处于rollbacking状态,然后再等待2分钟的时间,又会回滚一次,这次才把global_table里全局记录删除。为什么要回滚两次才删除,为什么花费这么长时间?

bejyjqdl

bejyjqdl3#

@ulwx Logs are printed in different threads, and the log time difference is greater than 2 minutes and 10 seconds, which is caused by the delay deletion mechanism.

感觉还是有问题,我调试了很多次,发现还是触发两次回滚,第一次回滚成功后,global_table里全局记录没有删除处于rollbacking状态,然后再等待2分钟的时间,又会回滚一次,这次才把global_table里全局记录删除。为什么要回滚两次才删除,为什么花费这么长时间?

slievrly has already answered this question, the two rollbacks are because of the asynchronous deletion mechanism. Global transactions will not be deleted immediately, but this does not affect business usage.

biswetbf

biswetbf4#

@ulwx Logs are printed in different threads, and the log time difference is greater than 2 minutes and 10 seconds, which is caused by the delay deletion mechanism.

感觉还是有问题,我调试了很多次,发现还是触发两次回滚,第一次回滚成功后,global_table里全局记录没有删除处于rollbacking状态,然后再等待2分钟的时间,又会回滚一次,这次才把global_table里全局记录删除。为什么要回滚两次才删除,为什么花费这么长时间?

slievrly has already answered this question, the two rollbacks are because of the asynchronous deletion mechanism. Global transactions will not be deleted immediately, but this does not affect business usage.

我也遇到了,为什么这样延迟删除呢,lock_table的row_key是主键,会造成其他操作同一条数据的全局事务2分钟内无法使用

相关问题