ob_trx_lock_timeout 参数异常

问题现象

存在的问题如下：

• 问题一：autocommit=true 情况下，ob_trx_lock_timeout 不生效。

• 问题二：autocommit=false 情况下，设置 ob_trx_lock_timeout=10s，事务内，前一条语句发生锁冲突但执行成功，等待 10s，执行后一条语句再次发生锁冲突（非更新同一行），第二条语句立即超时，未等 10s 。

• 问题三：autocommit=false 情况下，多行更新 ob_trx_lock_timeout 失效问题， 在当前实现中，如果出现行上锁成功，就会重置开始等锁时间点。假如语句更新 a，b，c 三行，第一次上 b 行锁失败，记录开始等锁时间点。后续重试的过程中，上 a 行锁成功，就会把开始等锁时间点重置，导致 ob_trx_lock_timeout 失效。

明确语义：ob_trx_lock_timeout 语义为在每一个锁上等待的超时时间。

语句存在多个不同行的锁冲突，会在每一行分别等一个 ob_trx_lock_timeout 的时间，而不是总时间为 ob_trx_lock_timeout 。如首先在行 1 发生锁冲突，ob_trx_lock_timeout 超时时间内行 1 释放，再在行 2 发生锁冲突，这时会再等待一个 ob_trx_lock_timeout 时间才超时。

关键诊断信息

触发条件

锁冲突。

事前巡检

无。

事后诊断

根据 autocommit 值和 ob_trx_lock_timeout 值以及是否发生锁冲突判断。

问题原因

• 问题一：autocommit=true，场景为历史遗留问题，V3.x 版本以来一直存在。

• 问题二：autocommit=false，V3.x 版本无此问题，在 V4.x 版本由于实现原因存在 BUG，V4.2.4 及后续版本已修复。

• 问题三：V2.2.x 该问题已修复，但未 V3.x 版本中修复，在 V4.x 版本无此问题。

问题的风险及影响

ob_trx_lock_timeout 参数未正常生效，语句在锁冲突场景长时间未超时结束。

影响租户

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

影响的版本

OceanBase 数据库企业版 V3.2.3 GA（20220419）及之后版本、V3.2.4 GA（oceanbase-3.2.4.0-100000072022102819）及之后版本、V4.1.0 GA（oceanbase-4.1.0.0-100001122023040322）及之后版本、V4.2.0 GA（oceanbase-4.2.0.0-100010082023083014）及之后版本、V4.2.1 GA（oceanbase-4.2.1.0-100000182023092722）及之后版本、V4.2.2 GA（oceanbase-4.2.2.0-100000082024011317）及之后版本、V4.3.0（oceanbase-4.3.0.0-100000072024020200）及之后版本。

• 问题一：autocommit=true 场景，除远程执行 ac=1 场景外，V4.2.4 版本及之前版本都存在此问题，V4.2.5 及之后版本修复。

• 问题二：autocommit=false 场景，V4.2.4 之前版本，V4.2.4 及后续版本已修复，V3.x 版本无此问题。

• 问题三：V3.2.3 BP10（oceanbase-3.2.3.3-110000092023091219）及之前版本、V3.2.4 BP8 Hotfix1（oceanbase-3.2.4.8-108010012024051118）版本及之前版本都存在此问题，V4.x 版本不存在此问题。

解决方法及规避方式

• 解决方法：

  升级至问题已修复版本。目前已修复的版本包括 OceanBase 数据库 V3.2.3 BP11（oceanbase-3.2.3.3-111000032024070822）、V3.2.4 BP8 Hotfix2（oceanbase-3.2.4.8-108020012024081520）、V3.2.4 BP8 Hotfix3（oceanbase-3.2.4.8-108030012024102211）、V4.2.1 BP7（oceanbase-4.2.1.7-107000112024052920）、V4.2.5 GA（oceanbase-4.2.5.0-100000082024102022）。

• 规避方式：

  • 问题一：autocommit=true 场景，避免使用 ob_trx_lock_timeout 参数。

  • 问题二：autocommit=false 场景，未修复该问题版本，尽量避免使用 ob_trx_lock_timeout 参数。

  • 问题三：尽量避免存在长期持锁未提交事务。

    如果本身业务就存在长期持锁未提交事务，推荐设置 ob_trx_lock_timeout 值小于等于 5s（请求兜底重试间隔）。