开源分布式数据库PolarDB-X源码解读——PolarDB-X源码解读(十一):事务的一生

本文涉及的产品
云原生数据库 PolarDB MySQL 版,通用型 2核4GB 50GB
云原生数据库 PolarDB PostgreSQL 版,标准版 2核4GB 50GB
简介: 开源分布式数据库PolarDB-X源码解读——PolarDB-X源码解读(十一):事务的一生

一、概述


本文将主要解读PolarDB-X中事务部分的相关代码,着重解读事务的一生在计算节点(CN)中的关键代码:从开始、执行、到最后提交这一整个生命周期。  


在阅读本文前,强烈推荐先阅读与PolarDB-X事务系统相关的文章:


 PolarDB-X 强一致分布式事务原理。

 PolarDB-X 分布式事务的实现(一)

 PolarDB-X 分布式事务的实现(二)InnoDB CTS 扩展

 PolarDB-X 分布式事务的实现(四):跨地域事务 *

 无处不在的 MySQL XA 事务

 PolarDB-X SQL 的一生


二、事务与连接


在PolarDB-X的CN层,与事务关系密切的是连接。这是因为数据节点(DN)也具备单个DN内的事务能力,CN则通过与DN的连接来管理DN上的事务,从而实现强一致的分布式事务能力。其中涉及到的连接大致如下图所示:  


                       

                                                                      事务与连接


先简单说一下这里面涉及的一些连接。ServerConnection类似于前端连接,大部分的SQL语句执行的入口都是ServerConnection#innerExecute。TConnection中的executeSQL方法负责SQL语句的真正执行,也负责创建新的事务对象。TConnection会一直引用着这个事务对象,直到事务提交或回滚。事务对象里有一个TransactionConnectionHolder,负责管理该事务用到的所有物理连接(CN连接DN的私有协议连接)。值得一提的是,ExecutionContext作为一条逻辑SQL执行的上下文,也会引用这个事务对象。这样,后续执行器需要使用物理连接与DN通信时,就可以通过ExecutionContext拿到事务对象,再通过事务对象的TransactionConnectionHolder拿到合适的物理连接。


以上的各种连接,都会在下文继续讨论。


三、两个例子


接下来,我们以两个简单的例子,来说明事务的一生在CN的代码中是如何体现的。  


测试用表:


CREATE TABLE `tb1` (
    `id` int PRIMARY KEY,
    `a` int
) DBPARTITION BY HASH(`id`)


先在里面插入几条数据:


INSERT INTO tb1 VALUES (0, 0), (1, 1), (2, 2), (3, 3);


测试使用的两个例子:


-- Transaction 1: 
BEGIN; 
SELECT * FROM tb1 WHERE id = 0; 
UPDATE tb1 SET a = 100 WHERE id = 1;
COMMIT;
-- Transaction 2: 
BEGIN; 
SELECT * FROM tb1 WHERE id = 0; 
UPDATE tb1 SET a = 101 WHERE id = 1;
UPDATE tb1 SET a = 101 WHERE id = 0;
COMMIT;


注意到事务2只比事务1多修改了id=0的数据。测试表是按id拆分的,因此id=0和id=1的记录会落在不同的物理分片上(假设分别为分片0和分片1)。事务1读了分片0,写了分片1,然后提交了事务,这将会触发我们对单分片写的“一阶段提交优化”。事务2读了分片0,随后写了分片1和分片0,然后提交了事务,这将会进行完整的分布式事务提交流程。这两个事务还会触发“只读连接优化”,即只有在第一次写的时候才真正开启分布式事务。


在接下来的讨论中,我们默认使用TSO事务策略和RR的隔离级别。


四、事务1的一生


1.BEGIN


与MySQL类似,要开启一个事务,一般有两种方式。


第一种方式是显式地执行BEGINSTART TRANSACTION [transaction_characteristic],执行这两种语句,会调用ServerConnection中的begin(boolean, IsolationLevel)方法。


第二种方式是执行SET autocommit=0,当前session会隐式开启事务,这种方式会调用ServerConnection中的setAutocommit(boolean, boolean)方法。


两种方式都会调用TConnectionsetAutoCommit方法。这些方法都只是简单地记录了一些变量(比如transaction_characteristic中设定的事务相关变量),同时标记这个连接开启了事务。此时,事务对象也还没创建出来,也没有与后端连接进行任何交互。


2.读分片0


在开启事务后,执行SELECT * FROM tb1 WHERE id = 0时,才会真正创建事务对象。根据事务与连接中的讨论,在TConnection中这条逻辑SQL的执行入口为executeSQL,里面会真正创建事务对象,主要执行逻辑为(代码出自PolarDB-X 5.4.13 release版本,为了方便说明,有删减及改动,下同):


// TConnection#executeSQL(ByteString, Parameters, TStatement, ExecutionContext)
public ResultSet executeSQL(ByteString sql, Parameters params, TStatement stmt,
                                ExecutionContext executionContext) throws SQLException {
  if (this.trx == null || this.trx.isClosed()) {
    // 开启事务后,直到执行第一条语句,才会创建事务对象。
    beginTransaction();
  }
  // 让 executionContext 引用 trx 对象,方便后续执行器通过 trx 对象拿物理连接。
  executionContext.setTransaction(this.trx);
  resultCursor = executeQuery(sql, executionContext, trxPolicyModified);
}
// TConnection#beginTransaction(boolean)
private void beginTransaction(boolean autoCommit) {
  // 根据一些默认的或用户设定的事务变量,选择合适的事务策略,比如 TSO/XA 等。
  trxPolicy = loadTrxPolicy(executionContext);
  TransactionClass trxConfig = trxPolicy.getTransactionType(autoCommit, readOnly);
  // 根据事务策略,创建出对应的事务对象。
  this.trx = transactionManager.createTransaction(trxConfig, executionContext);
}
在我们的例子中,如果在上述代码打个断点,可以看到创建出来的是TsoTransaction,其中一些值得关注的变量为:
trx = {TsoTransaction}
    // 此时还没有获取任何时间戳。
    snapshotTimestamp = -1
    commitTimestamp = -1
    // 事务写的第一个物理分片(下称主分片),事务日志将会写在这个分片上。
  primaryGroup = null
    // 该事务是否跨分片,如果是单分片事务,会优化为一阶段提交。
    isCrossGroup = false
    // 事务日志管理器,负责写事务日志。
    globalTxLogManager = {GlobalTxLogManager}
    // 分布式事务的 connectionHolder 都是 TransactionConnectionHolder,
    // 里面分别存储了读写连接,读连接和写连接在提交时行为会有所不同。
    connectionHolder = {TransactionConnectionHolder}
        // 物理分片到对应写连接的映射。
        groupHeldWriteConn = {HashMap}
        // 物理分片到对应读连接集合到映射。在 ShareReadView 优化开启时,
        // 可以同时存在多个读连接和一个写连接,因此这里读写连接需要分开管理。
        // 该优化不在本文展开。
        groupHeldReadConns = {HashMap}


在执行器阶段,会选择给分片0下发一条SELECT语句,此时需要获取分片0的物理连接,代码入口是MyJdbcHandler中的getPhyConnection(ITransaction,ITransaction.RW,String,DataSource)方法。其中的事务对象Transaction则是从ExecutionContext里拿到。该方法最后会调用AbstractTransaction(这是所有分布式事务类的基类)中的getConnection方法。  


通过事务拿物理连接的代码AbstractTransaction#getConnection如下:


// AbstractTransaction#getConnection(String, String, IDataSource, RW, ExecutionContext)
public IConnection getConnection(String schema, String group, IDataSource ds, RW rw, ExecutionContext ec) {
  if (/* 是事务的第一个写请求 */) {
    // 把这个分片作为主分片,事务日志将写在这个分片上。
    this.primaryGroup = group;
    // 该分片还用于生成 XA 事务的 xid。
    this.primaryGroupUid = IServerConfigManager.getGroupUniqueId(schema, group);
  }
  // 通过 connectionHolder 拿到物理连接。
  IConnection conn = connectionHolder.getConnection(schema, group, ds, rw);
  if (/* 是写请求 */ && !isCrossGroup && !this.primaryGroup.equals(group)) {
    // 事务涉及了多个分片。
    this.isCrossGroup = true;
  }
  return conn;
}


在我们的例子中,上述参数group是物理分片0,rw是READ,说明需要物理分片0上的读连接,ds则主要用于生成物理连接。由于我们只是读请求,因此分片0不会作为主分片,会直接返回connectionHolder.getConnection(schema,group,ds,rw)的结果。


通过连接管理器拿物理连接的代码TransactionConnectionHolder#getConnection如下:


// TransactionConnectionHolder#getConnection(String, String, IDataSource, RW)
public IConnection getConnection(String schema, String group, IDataSource ds, RW rw) {
  // 尝试获取该分片上的写连接,如果有,直接返回这个写连接。
  HeldConnection groupWriteConn = groupHeldWriteConn.get(group);
  if (groupWriteConn != null) {
    return groupWriteConn.connection;
  }
  HeldConnection freeReadConn = /* 尝试找到读连接 */;
  if (freeReadConn != null) {
    if (/* 当前需要写连接 */) {
      // 设置当前连接为写连接,participated = true 意味着该连接是写连接。
      freeReadConn.participated = true;
      this.groupHeldWriteConn.put(group, freeReadConn);
      // 由于原本是读连接,这里才真正开启分布式事务。
      this.trx.commitNonParticipant(group, freeReadConn.connection);
      this.trx.begin(schema, freeReadConn.group, freeReadConn.connection);
    }
    return freeReadConn.connection;
  }
  // 当前分片没有任何连接,创建一个新的连接。还会根据读写类型,
  // 设置好写连接 groupHeldWriteConn 或读连接集合 groupHeldReadConns。
  IConnection conn = new DeferredConnection(/* 这里会获取并封装该分片的私有协议连接 */);
  if (/* 需要写连接 */) {
    // 开启正常的分布式事务。
    this.trx.begin(schema, group, conn);
  } else {
    // 优化为只读事务。
    this.trx.beginNonParticipant(group, conn);
  }
  return conn;
}


在我们的例子中,由于是第一条语句,该分片上还没有任何连接,因此会先生成一个连接该分片的私有协议连接,包装成DeferredConnection,然后因为是读请求,会调用beginNonParticipant。  


TsoTransactionbeginNonParticipant方法如下:  


// TsoTransaction#beginNonParticipant(String, IConnection)
protected void beginNonParticipant(String group, IConnection conn) throws SQLException {
  if (snapshotTimestamp < 0) {
    // 该事务从未拿过时间戳,则在这里获取。
    snapshotTimestamp = nextTimestamp();
  }
  // 使用私有协议的流水线执行机制执行 BEGIN。
  conn.executeLater("BEGIN");
  // 在 BEGIN 后发送时间戳。
  sendSnapshotSeq(conn);
}


在我们的例子中,私有协议连接会流水线执行BEGIN语句(非阻塞,不等结果返回),且在稍后执行物理SQL时才发送时间戳。至此,连接上的一些初始化操作已经完成,可以向执行器返回并执行读分片0的物理SQL。


3.写分片1


随后,我们执行UPDATE tb1 SET a = 100 WHERE id = 1。在执行器阶段,需要给分片1下发一条UPDATE语句,此时需要获取分片1的物理连接,因此又会调用AbstractTransaction#getConnection方法,通过事务对象拿物理连接。通过前面贴出的代码,我们发现由于是事务的第一个写请求,因此分片1会视作主分片,用于生成xid和稍后记录事务日志。


在获取物理连接时,又会调用TransactionConnectionHolder#getConnection方法,通过连接管理器拿物理连接。通过前面贴出的代码,我们发现由于分片1没有任何连接,因此会生成一个私有协议连接,包装成DeferredConnection。与读分片0不同,由于是写请求,会执行TsoTransaction的begin方法。


TsoTransactionbegin方法如下:


// TsoTransaction#begin(String, String, IConnection)
protected void begin(String schema, String group, IConnection conn) throws SQLException {
  if (snapshotTimestamp < 0) {
    // 该事务从未拿过时间戳,则在这里获取。
    snapshotTimestamp = nextTimestamp();
  }
  // 获取 xid。
  String xid = getXid(group);
  // 触发私有协议流水线执行 XA START。
  conn.executeLater("XA START " + xid);
  // 在 XA START 后发送时间戳。
  sendSnapshotSeq(conn);
}


简单来说,和此前beginNonParticipant方法唯一的区别在于,使用了XA START开启事务。根据MySQL关于XA事务的说明,xid由gtrid[,bqual[,formatID]]组成,这里的gtrid是“drds-事务id @主分片Uid”,这样保证了同一个事务在不同分片上执行XA START,会使用相同的gtridbqual设置当前连接的分片,用于在事务恢复时确定分支事务所在的分片。在我们的例子中,xid为:'drds-13e101d74e400000@5ae6c3b5be613cd1','DB1_000001_GROUP',其中13e101d74e400000是事务id,5ae6c3b5be613cd1是分片1的Uid,DB1_000001_GROUP是分片1的具体分片名称。值得注意的是,这里会把之前的时间戳发送到分片1。至此,连接上的一些初始化操作已经完成,可以向执行器返回并执行写分片1的物理SQL。


4.COMMIT


最后,执行COMMIT提交事务。处理COMMIT的代码入口为ServerConnection#commit(),其主要调用了TConnection#commit方法,代码如下:


// TConnection#commit()
public void commit() throws SQLException {
  try {
    // 触发事务的提交流程。
    this.trx.commit();
  } finally {
    // 大部分情况下,如果事务提交成功,或出现异常后正确处理了,
    // 所有连接会被关闭并释放,trx.close() 相当于什么也不做。
    // 但如果事务提交失败且没有处理,这里会回滚事务并释放所有物理连接。
    this.trx.close();
    // 去掉对这个事务对象的引用,意味着当前连接里这个事务一生的结束。
    this.trx = null;
  }
}


我们重点关注一下事务的提交流程,上述this.trx.commit()调用时,会调用ShareReadViewTransaction(该类继承了AbstractTransaction,基于XA事务实现了共享readview的功能,XATransaction和TsoTransaction都会继承这个类,在这里可以简单理解为XA事务的基类)的commit方法,代码如下:


// ShareReadViewTransaction#commit()
public void commit() {
  if (!isCrossGroup) {
    // 如果只涉及了单个分片的写,进行一阶段提交优化。
    commitOneShardTrx();
  } else {
    // 正常的多分片分布式事务提交流程。
    commitMultiShardTrx();
  }
}


在我们的例子中,由于只写了分片1,所以进入一阶段提交优化,代码如下:


// ShareReadViewTransaction#commitOneShardTrx()
protected void commitOneShardTrx() {
  // 对持有的所有物理连接执行以下流程,以提交每个物理连接开启的事务。
  forEachHeldConnection((group, conn, participated) -> {
      if (!participated) {
        // 只读连接是 BEGIN 开启事务的,且只有读操作,执行 ROLLBACK 即可。
        conn.execute("ROLLBACK");
      } else {
        // 获取 xid。
        String xid = getXid(group);
        // 写连接是 XA START 开启事务的,执行 XA END 和 XA COMMIT ONE PHASE 提交事务。
        conn.execute("XA END " + xid + "; XA COMMIT " + xid + " ONE PHASE");
      }
  });
  // 所有连接都提交了分支事务,释放并清空这些物理连接。
  connectionHolder.closeAllConnections();
}


我们一共持有了2个物理连接。对于分片0的只读连接,会直接执行ROLLBACK;对于分片1的写连接,则执行XA ENDXA COMMIT ONE PHASE提交事务。注意到我们并没有获取commit timestamp,因为在一阶段提交优化里,commit timestamp会由InnoDB计算生成:


*具体的计算规则是:COMMIT_TS = MAX_SEQUENCE+1,其中MAX_SEQUENCE为InnoDB本地维护的历史最大的snapshot_ts。


如果提交失败了,会调用事务的close方法,代码如下:


// AbstractTransaction#close()
public void close() {
  // 回滚所有物理连接上的事务。
  cleanupAllConnections();
  // 释放并清空这些物理连接。
  connectionHolder.closeAllConnections();
}


值得一提的是,cleanupAllConnections()也是ROLLBACK语句主要调用的方法。因此为了同时了解ROLLBACK语句执行流程,我们也看一下cleanupAllConnections方法的代码:


// AbstractTransaction#cleanupAllConnections()
protected final void cleanupAllConnections() {
  // 对持有的所有物理连接执行以下流程,以回滚每个物理连接开启的事务。
  forEachHeldConnection((group, conn, participated) -> {
    if (conn.isClosed()) { return; }
    if (!participated) {
      // 只读连接是 BEGIN 开启事务的,且只有读操作,执行 ROLLBACK 即可。
      conn.execute("ROLLBACK");
    } else {
      // 获取 xid。
      String xid = getXid(group);
      // 写连接是 XA START 开启事务的,执行 XA END 和 XA ROLLBACK 回滚事务。
      conn.execute("XA END " + xid + "; XA ROLLBACK " + xid);
    }
  });
}


可以看到,回滚的逻辑是看情况执行ROLLBACKXA ROLLBACK来回滚事务的。


至此,我们看到了事务1的一生。接下来看一下多分片写的事务流程。


五、事务2的一生  


1.写分片0


事务2中,从开启事务到执行UPDATE tb1 SET a = 101 WHERE id = 1走的流程和事务1一样,直到执行UPDATE tb1 SET a = 101 WHERE id = 0时,才有所不同。具体而言,事务在之前就获取了分片0的只读连接,当执行到TransactionConnectionHolder#getConnection时,会先提交只读连接上的事务(实际执行了ROLLBACK),然后在这条连接上用XA START开启XA事务,设置好时间戳,就可以把这个物理连接返回给执行器,最终执行物理SQL。由于这是第二个写连接,因此还会设置事务为跨分片事务,以触发正常的两阶段提交流程。


2.COMMIT


事务2的重点在于写了2个分片,因此COMMIT时会调用commitMultiShardTrx()走多分片的分布式提交流程。方法commitMultiShardTrx代码如下:  


// TsoTransaction#commitMultiShardTrx()
protected void commitMultiShardTrx() {
  // 事务日志的提交状态,一共有 3 种:FAILURE,UNKNODWN,SUCCESS。
  TransactionCommitState commitState = TransactionCommitState.FAILURE;
  try {
    // 对所有连接执行 XA prepare。
    prepareConnections();
    // 拿 commit 时间戳。
    commitTimestamp = nextTimestamp();
    Connection logConn = /* 获取主分片上的连接 */;
    // 所有分支事务 prepare 成功,在写事务日志前,状态设置为 UNKNOWN,其作用见后续代码说明。
    commitState = TransactionCommitState.UNKNOWN;
    // 写事务日志。
    writeCommitLog(logConn);
    // 写事务日志成功,状态置为 SUCCESS。
    commitState = TransactionCommitState.SUCCESS;
  } catch (RuntimeException ex) {
    exception = ex;
  }
  if (commitState == TransactionCommitState.FAILURE) {
    // 写事务日志前失败了,回滚所有连接。
    rollbackConnections();
  } else if (commitState == TransactionCommitState.SUCCESS) {
    // 写事务日志成功了,提交所有连接。
    commitConnections();
  } else {
    // 所有连接都 prepare 成功了,但无法确定是否写入了事务日志,
    // 将由事务恢复的逻辑来决定是 COMMIT 还是 ROLLBACK。这里先丢弃所有连接。
    discardConnections();
  }
  // 释放并清空这些物理连接。
  connectionHolder.closeAllConnections();
  // prepare 或 commit 阶段抛出的异常,这里重新抛出。
  if (exception != null) {
      throw exception;
  }
}


上述代码正是两阶段提交的流程。


在prepare阶段,调用prepareConnections(),其中对只读连接只是简单执行ROLLBACK语句;对于写连接,执行XA END {xid}XA PREPARE {xid}语句。  


如果所有连接都prepare成功了,在commit阶段,调用writeCommitLog(logConn),用主分片(在我们的例子中,是分片1)的连接,写下事务日志,主要包括了事务的id和commit时间戳,事务日志主要用于后续的事务恢复。


如果事务日志写成功了,就意味着commit成功了,会调用commitConnections()对所有连接进行提交,这一步只用对写连接设置commit时间戳SET innodb_commit_seq = {commitTimestamp}和执行XA COMMIT {xid}语句。


如果在写事务日志前失败了,会调用rollbackConnections()对所有连接进行回滚,主要会对写连接执行XA ROLLBACK {xid}回滚。


如果无法确定是否成功写入了事务日志,事务的状态会是UNKNOWN。此时,我们能确定所有分支事务都成功prepare了,如果事务日志写入成功了,则要进行XA COMMIT;如果事务日志没有写入,则要进行XA ROLLBACK。由于不确定是要提交还是回滚,我们会丢弃所有物理连接,使这些连接后续不再可用。至于事务最终是提交还是回滚,则交给事务恢复线程来处理,接下来我们会解读事务恢复相关的代码。  


3.事务恢复


一个分布式事务在提交的时候,可能遇到各种情况导致提交失败。例如,所有分支事务都prepare成功了,事务日志也写入成功了,但XA COMMIT失败了。对于这种情况,事务恢复时需要正确提交所有分支事务。另一种情况是,部分分支事务prepare成功了,另外一些失败了,或事务日志没有写入成功。对于这种情况,事务恢复需要回滚掉已prepare的分支事务。


事务恢复主要由XARecoverTask负责。其主体代码为recoverInstance方法,该方法检查一个DN下的所有prepare过的事务,并根据事务状态提交或回滚这些事务,代码如下:  


// XARecoverTask#recoverInstance(IDataSource, Set<String>)
// dataSource 用户获取 DN 的连接,groups 是当前逻辑库的所有物理分片
private void recoverInstance(IDataSource dataSource, Set<String> groups) {
  // 执行 XA RECOVER 获取该 DN 上所有 prepare 的事务。
  // 此处省略了从 dataSource 获取连接和生成 statement 的代码。
  ResultSet rs = stmt.executeQuery("XA RECOVER");
  while (rs.next()) {
    // 对每一条记录,生成对象 PreparedXATrans,
    // 主要包括 xid,事务id,分支事务所在的分片,主分片等信息。
    PreparedXATrans trans = /* 从 rs 中获取一行数据生成 */;
    if (/* trans 所在分片是当前逻辑库的一个物理分片 && 
        trans 在上一次 recover 任务时也出现过,
        即较长时间都未被提交或回滚*/) {
      // 介入处理这个分支事务:回滚或提交。
      rollBackOrForward(trans, stmt);
    }
  }
}


该任务每5秒到每个DN上执行一次XA RECOVER,得到所有prepare过的事务,如果看到一个事务在上一次任务中也出现过,即至少过去5秒都没有提交或回滚,则会选择对这个事务进行回滚或提交。相关逻辑代码为rollBackOrForward,代码如下:


// XARecoverTask#rollBackOrForward(PreparedXATrans, Statement)
private boolean rollBackOrForward(PreparedXATrans trans, Statement stmt) throws SQLException {
  String primaryGroup = /* 从 trans 里解析出主分片,详见前文关于 xid 的生成 */;
  // 尝试从主分片的事务日志中找到相关的事务日志。
  GlobalTxLog tx = GlobalTxLogManager.get(primaryGroup, trans.transId);
  if (tx != null) {
    // 确实存在事务日志,根据事务日志状态判断回滚或提交。
    if (tx.getState() == TransactionState.ABORTED) {
      // ABORTED 状态的事务需要回滚。
      return tryRollback(stmt, trans);
    } else {
      // SUCCESS 状态的事务需要提交。
      return tryCommitTSO(stmt, trans, tx.getCommitTimestamp());
    }
  } else {
    // 没有找到事务日志,尝试回滚,先开启事务,写下事务日志,标记事务为 ABORTED。
    try (Connection conn2 = /* 获取主分片上的另一个连接 */;) {
      conn2.setAutocommit(false);
      // 尝试回滚,如果因为别的线程正在处理这个事务
      //(比如该事务只是提交得慢,连接仍未断开,还在提交流程)
      // 而报错,就回滚上一条写事务日志的语句。
      txLog.append(transInfo.transId, TransactionType.XA, TransactionState.ABORTED, new ConnectionContext(), conn2);
      stmt.execute("XA ROLLBACK " + trans.toXid());
      conn2.commit();
      return true;
    } catch (Exception e) {
      /* 根据异常判断是否要回滚写事务日志的操作 */
    }
  }
}


该方法主要有3段逻辑。  


一是如果存在对应的事务日志,且事务状态是ABORTED,那就执行tryRollback方法回滚,该方法主要执行了XA ROLLBACK {xid}


二是如果事务状态是SUCCESS,那就执行tryCommitTSO方法回滚,该方法会设置commit时间戳,然后执行XA COMMIT {xid}


三是如果没找到事务日志,此时一般有两种可能:


 事务提交失败了,且没写下事务日志,此时需要回滚。  

 事务还在两阶段提交的流程中,只是prepare较慢,还没开始写事务日志,此时不需要做任何操作。


在MySQL中,如果发起XA START的连接没有关闭,其他连接是无法通过XA ROLLBACKXA COMMIT来回滚或提交这个分支事务的。我们利用这一特性,首先在事务日志插入一条ABORTED记录,表明这个分布式事务需要回滚,然后尝试执行XA ROLLBACK回滚这个分支事务。


如果遇到2)的情况,则会收到特定的报错,此时再回滚掉插入ABORTED事务日志的操作。在我们插入ABORTED事务日志后,原本正在提交事务的线程在插入SUCCESS事务日志时会被阻塞,而在我们回滚掉插入ABORTED事务日志的操作后,事务提交流程就会继续进行下去。


六、小结


本文主要解读了PolarDB-X中CN端的事务相关的代码,以TSO事务为主,使用两个例子,一步步地展示了事务的开启、执行、提交、恢复等流程。希望大家阅读本文后,能更加了解PolarDB-X的事务系统。

相关实践学习
快速体验PolarDB开源数据库
本实验环境已内置PostgreSQL数据库以及PolarDB开源数据库:PolarDB PostgreSQL版和PolarDB分布式版,支持一键拉起使用,方便各位开发者学习使用。
相关文章
|
3月前
|
SQL 关系型数据库 MySQL
乐观锁在分布式数据库中如何与事务隔离级别结合使用
乐观锁在分布式数据库中如何与事务隔离级别结合使用
|
1月前
|
SQL 关系型数据库 MySQL
乐观锁在分布式数据库中如何与事务隔离级别结合使用
乐观锁在分布式数据库中如何与事务隔离级别结合使用
|
3月前
|
存储 SQL 分布式数据库
OceanBase 入门:分布式数据库的基础概念
【8月更文第31天】在当今的大数据时代,随着业务规模的不断扩大,传统的单机数据库已经难以满足高并发、大数据量的应用需求。分布式数据库应运而生,成为解决这一问题的有效方案之一。本文将介绍一款由阿里巴巴集团自主研发的分布式数据库——OceanBase,并通过一些基础概念和实际代码示例来帮助读者理解其工作原理。
317 0
|
13天前
|
消息中间件 监控 数据可视化
Apache Airflow 开源最顶级的分布式工作流平台
Apache Airflow 是一个用于创作、调度和监控工作流的平台,通过将工作流定义为代码,实现更好的可维护性和协作性。Airflow 使用有向无环图(DAG)定义任务,支持动态生成、扩展和优雅的管道设计。其丰富的命令行工具和用户界面使得任务管理和监控更加便捷。适用于静态和缓慢变化的工作流,常用于数据处理。
Apache Airflow 开源最顶级的分布式工作流平台
|
13天前
|
关系型数据库 分布式数据库 数据库
PostgreSQL+Citus分布式数据库
PostgreSQL+Citus分布式数据库
45 15
|
18天前
|
关系型数据库 MySQL Linux
在 CentOS 7 中通过编译源码方式安装 MySQL 数据库的详细步骤,并与使用 RPM 包安装进行了对比
本文介绍了在 CentOS 7 中通过编译源码方式安装 MySQL 数据库的详细步骤,并与使用 RPM 包安装进行了对比。通过具体案例,读者可以了解如何准备环境、下载源码、编译安装、配置服务及登录 MySQL。编译源码安装虽然复杂,但提供了更高的定制性和灵活性,适用于需要高度定制的场景。
55 3
|
18天前
|
PHP 数据库 数据安全/隐私保护
布谷直播源码部署服务器关于数据库配置的详细说明
布谷直播系统源码搭建部署时数据库配置明细!
|
21天前
|
关系型数据库 MySQL Linux
在 CentOS 7 中通过编译源码方式安装 MySQL 数据库的详细步骤,包括准备工作、下载源码、编译安装、配置 MySQL 服务、登录设置等。
本文介绍了在 CentOS 7 中通过编译源码方式安装 MySQL 数据库的详细步骤,包括准备工作、下载源码、编译安装、配置 MySQL 服务、登录设置等。同时,文章还对比了编译源码安装与使用 RPM 包安装的优缺点,帮助读者根据需求选择最合适的方法。通过具体案例,展示了编译源码安装的灵活性和定制性。
64 2
|
1月前
|
关系型数据库 MySQL Linux
在 CentOS 7 中通过编译源码方式安装 MySQL 数据库的详细步骤
本文介绍了在 CentOS 7 中通过编译源码方式安装 MySQL 数据库的详细步骤,包括准备工作、下载源码、编译安装、配置服务等,并与使用 RPM 包安装进行了对比,帮助读者根据需求选择合适的方法。编译源码安装虽然复杂,但提供了更高的定制性和灵活性。
232 2
|
2月前
|
JavaScript Java 关系型数据库
毕设项目&课程设计&毕设项目:基于springboot+vue实现的在线考试系统(含教程&源码&数据库数据)
本文介绍了一个基于Spring Boot和Vue.js实现的在线考试系统。随着在线教育的发展,在线考试系统的重要性日益凸显。该系统不仅能提高教学效率,减轻教师负担,还为学生提供了灵活便捷的考试方式。技术栈包括Spring Boot、Vue.js、Element-UI等,支持多种角色登录,具备考试管理、题库管理、成绩查询等功能。系统采用前后端分离架构,具备高性能和扩展性,未来可进一步优化并引入AI技术提升智能化水平。
毕设项目&课程设计&毕设项目:基于springboot+vue实现的在线考试系统(含教程&源码&数据库数据)

相关产品

  • 云原生数据库 PolarDB