源码是 OceanBase 的“方向盘”，本系列主要围绕“源码解读”，通过文章阐述，帮助大家理清数据库的内在本质。此前，带你读源码第三篇《戳这里回顾：
OceanBase 源码解读（三）分区的一生》为大家介绍了OceanBase 的存储层的相关内容。在第一节讲通信协议
obmp_query
时，跳过了事务控制的细节，本文为 OceanBase 数据库源码解读系列文章的第四篇，将主要为大家介绍事务的外部接口相关知识。
事务的外部接口
1.1. 协议层对事务层的封装
协议层对事务层提供的原始接口进行了封装，源码位置：sql/ob_sql_trans_control.h，截图如下。这层封装维护了
TransState
状态，且便于 SQL 层调用，语句执行结束时在统一的位置根据
TransState
调用正确的事务接口，保证在任何异常状态下事务资源不泄露。
2.2. 原始的事务接口
原始的事务接口位于源码文件 storage/transaction/ob_trans_service.h，主要接口为：
-
start_trans
end_trans
-
start_stmt
end_stmt
-
start_participant
end_participant
它们分别对应事务、语句、语句内参与者（分区）的访问生命周期。
start trans
开启事务后，返回一个
ObTransDesc
对象。该对象作为事务唯一标识，会被保存到
session
对象中，其他事务接口和后续语句执行都需要它，也常用于问题诊断。
3.3. 分布式事务
开始执行前，根据语句涉及分区信息从
location cache
中获取主副本（leader）位置，选择对应类别的执行计划。一般的，一个 SQL 查询或 DML 会产生三类执行计划（
ObPhyPlanType
）：
-
local
-
remote
-
distributed
location cache
是一个整体架构上的重要组件，用于高效查找分区副本信息，它对外提供统一接口，屏蔽了很多分布式细节。它的主体实现位于 share/partition_table目录（参见截图），而源文件 sql/ob_sql_partition_location_cache.h 对它进行了封装，同时统一了虚拟表的处理。
事务控制调用往往要综合考虑多种因素：
- 语句类型（是否只读）
- 事务类型（是否自动提交，是否弱一致性读）
- 当前事务状态和执行计划类型等
例如，本地计划自动提交，在本节点顺序执行
start_trans
➡︎
start_stmt
start_participant
end_participant
end_stmt
end trans
；远程计划自动提交，上述接口都在远程节点执行。而对于分布式执行计划，
start/end_stmt
在本节点执行，
start/end_participant
在每个分区 leader 所在节点上执行。这组接口设计目的是在简化事务接口与分场景优化事务性能间取得一定的平衡。
以上就是 OceanBase 事务的一生，在后续的源码解读第五篇我们将会为大家解析 OceanBase 数据库多租户架构的相关内容，敬请期待。