OceanBase 数据库 V3.2.3 版本中 ob_trx_idle_timeout 失效说明

问题现象

OceanBase 租户级别事务超时变量有 ob_trx_idle_timeout 和 ob_trx_timeout, 它们分别控制事务 SQL 空闲时间和整体事务的执行时间，在部分 OceanBase 数据库 V3.2.3 release 版本中存在 ob_trx_idle_timeout 空闲超时失效的情况，本文主要给出排查手段和原因。

问题原因

OceanBase 数据库系统参考两个时间点的取值来判断是否出现事务空闲超时。一个时间点是当前事务中上一条语句的结束时间，用 curr_trans_last_stmt_end_time 来表示，另一个时间点是上一条语句的执行开始时间，使用 last_query_start_ts 来表示。当 last_query_start_ts < curr_trans_last_stmt_end_time 的时候，系统进入事务空闲是否超时判断逻辑。

OceanBase 数据库为了性能考虑，代码内部实现缓存时钟（ObClockGenerator），以提高时钟获取效率。在出现变量 ob_trx_idle_timeout 失效的版本里，当缓存时钟尚未初始化的时候（clock_generator.inited），curr_trans_last_stmt_end_time 的值从系统时间直接获取；当内部时钟已经完成初始化之后，curr_trans_last_stmt_end_time 则直接通过原语 ATOMIC_LOAD 获取当前时间的缓存值（cur_ts）。如果缓存值与实际系统时间二者出现偏差，导致判断逻辑 last_query_start_ts < curr_trans_last_stmt_end_time 无法成立，用户则会观察到 ob_trx_idle_timeout 无法生效的问题现象。如下代码段：

其中，当 curr_trans_last_stmt_end_time < last_query_start_ts 的时候导致失效，可以通过打印 debug 日志的方式，观测 last_query_start_ts 和curr_trans_last_stmt_endtime 实际值，帮助我们进行判断。这里需要注意，调整日志为 debug 级别也不保证这条 debug 日志一定会打印：

而 curr_trans_last_stmt_end_time 值取值来自如下：

session.set_curr_trans_last_stmt_end_time(ObClockGenerator::getClock());

为了性能考虑通过内部实现的缓存时钟来提供时钟获取接口，通过原语 load 来获取当前时间戳缓存值赋予给 curr_trans_last_stmt_end_time，

关键信息

当发现应用事务运行时间未达到空闲时间，而达到事务超时时间时候，可以从日志中去寻找如下信息，确认 end_trans 走到了事务超时逻辑，从而帮助我们区分和确认 是事务空闲超时或者事务超时造成的事务中断问题。

WARN [STORAGE.TRANS] end_trans (ob_trans_service.cpp:1047) [114707][0][xxxxx-xxxxx-xxxxx-xxxxx] [lt=7] [dc=0] transaction timeout and already terminated(trans_desc={tenant_id:1010, trans_id:{hash:15617973398524307547, inc:70296278683, addr:"xxx.xxx.xxx.xxx:xxx", t:1713860598605354}

参考代码片段：

问题的风险及影响

应用事务空闲超时一般 120s，事务超时时间是 600s。如果遇到事务空闲超时失效的情况，可能会导致非预期的，甚至严重的阻塞问题。比如，用户希望设置事务空闲失效时间来避免过长的锁等待， 一旦遇到行锁冲突而且事务空闲超时失效，业务系统就需要等待事务超时（600s）而不是事务空闲超时（120s）才能释放锁资源。

影响租户

影响 OceanBase 数据库中的 SYS 租户和 Oracle 租户以及 MySQL 租户。

适用版本

OceanBase 数据库 V3.x 版本。

解决方法及规避方式

• 解决方法：

  如果应用依赖空闲超时时间，可以升级到 OceanBase 数据库 V3.2.3 BP10（oceanbase-3.2.3.3-110000092023091219）及之后版本。

  注意

  ob_trx_idle_timeout空闲超时时间在 OceanBase 数据库 V4.x版本后已不再使用。

• 规避方式：

  无 。