DB2 SELECT行隔离失效：为何排他锁未阻止并行应用更新？

我来帮你拆解下这个问题——你遇到的核心问题是设置的排他锁没有持续保持，导致并行UPDATE可以成功执行，大概率和DB2 z/OS的锁生命周期、事务边界有关，以下是具体分析和验证步骤：

1. 最可能的原因：自动提交（Auto-Commit）开启导致锁立即释放 #

DB2 z/OS的多数客户端（比如DB2 CLP、JDBC默认配置）默认开启自动提交模式。在这种模式下，你执行的那条带锁的SELECT语句一旦执行完成，事务会自动提交，此时获取的排他锁会被立即释放。后续的UPDATE语句自然能顺利执行，因为锁已经不存在了。

验证与解决方法： #

• 在执行SELECT前，先关闭自动提交：

  SET AUTOCOMMIT OFF;
  

• 执行你的排他锁查询：

  select COL from mdmsysdb.test WITH RS USE AND KEEP EXCLUSIVE LOCKS;
  

• 此时打开另一个会话执行UPDATE，你会发现UPDATE被阻塞，直到第一个会话显式执行COMMIT或ROLLBACK释放锁。

2. 其他可能的排查点 #

如果关闭自动提交后问题仍存在，可以检查以下内容：

• 确认锁的实际范围：如果你的表数据量极小（比如只有1行），DB2可能会触发锁升级，将行锁升级为表锁？不过这种情况下UPDATE应该会被阻塞，所以概率较低。你可以通过DB2的锁监控工具（比如-DISPLAY LOCKS命令）查看实际的锁类型和持有情况。
• 检查隔离级别的生效情况：虽然你在语句中指定了WITH RS/RR，但可以确认会话的当前隔离级别是否被正确覆盖：

  SELECT CURRENT ISOLATION FROM SYSIBM.SYSDUMMY1;
  

• 确认USE AND KEEP EXCLUSIVE LOCKS的适用场景：这个子句对于动态SQL的单条SELECT语句是生效的，但如果是通过游标执行的查询，需要确保游标没有被提前关闭，锁才会保持到事务结束。

总结 #

绝大多数情况下，自动提交开启是导致锁无法保持的核心原因。只要确保在事务中执行带锁的SELECT，并且显式控制事务的提交/回滚，就能实现预期的行锁定效果。

内容的提问来源于stack exchange，提问作者Waseem Ahmed