GridDB错误码TXN_STATEMENT_TYPE_NOT_EXECUTABLE排查求助

一、行锁正确设置规范 #

GridDB对行锁的使用有严格场景限制，需满足以下条件：

• 仅支持特定操作：只有带精准WHERE条件（基于主键/索引列）的UPDATE/DELETE/SELECT FOR UPDATE操作可使用行锁，批量更新、全表操作、DDL语句（建表/删表）不支持行锁，强行指定会触发该错误。
• SQL层面指定方式：在支持行锁的语句后追加FOR UPDATE，示例：

  -- 正确用法：基于主键定位单行并加行锁
  SELECT * FROM user WHERE id = 100 FOR UPDATE;
  UPDATE user SET name = 'new_name' WHERE id = 100;
  

• 客户端API层面：使用Java/Python等客户端时，需确保事务模式为READ_WRITE，并明确指定锁模式（如Java中setLockMode(LockMode.PESSIMISTIC_WRITE)），且仅对支持行锁的操作生效。

二、额外排查方向 #

1. 检查事务隔离级别
   GridDB默认隔离级别为READ_COMMITTED，若改为REPEATABLE_READ可能引发锁冲突，可执行以下命令重置：

   SET TRANSACTION ISOLATION LEVEL READ COMMITTED;
   

2. 验证表类型
   时间序列表（TIME_SERIES）不支持行锁操作，需确认操作对象为集合表（COLLECTION）。可通过gs_sh登录后执行以下命令查看表类型：

   SHOW TABLES WITH DETAILS;
   

3. 排查环境与服务状态

   • 重启GridDB服务：sudo systemctl restart griddb
   • 重启WSL实例：wsl --shutdown后重新启动，避免网络延迟导致的锁状态异常

4. 查看详细日志
   查看GridDB日志获取错误上下文，默认日志路径为/var/log/gridstore/，重点检查gs_node.log和gs_sql.log，定位触发错误的具体语句或操作。

三、验证测试 #

执行最简行锁测试语句，验证基础功能是否正常：

BEGIN;
SELECT * FROM your_table WHERE id = 1 FOR UPDATE;
UPDATE your_table SET value = 100 WHERE id = 1;
COMMIT;

若测试成功，说明行锁设置无问题，需排查业务SQL的合理性；若测试失败，优先检查表类型或服务端配置。

内容的提问来源于stack exchange，提问作者omar esawy