DB2 for z/OS V11中CURSOR FOR UPDATE锁行为相关问题咨询

问题1：带FOR UPDATE子句的游标是否会阻止并发事务读取当前定位行？ #

• 结论是不会
• 原理：CS隔离级别下，FOR UPDATE游标执行FETCH操作时仅会为目标行加更新锁（U-Lock），DB2锁兼容规则中U-Lock与共享锁（S-Lock）兼容，其他并发事务只要不修改该行，可正常申请S-Lock读取该行数据，不会被阻塞。

问题2：UPDATE ... WHERE CURRENT OF ...是否可检测到游标打开后、FETCH该行前行已被修改的情况？ #

该行为由BIND命令的CURRENTDATA参数决定，V11版本默认值为CURRENTDATA(NO)：

• 默认配置下，FOR UPDATE游标OPEN阶段不会锁行，执行FETCH操作时DB2会自动校验目标行是否在游标打开后被其他事务提交修改，如果已变更会重新读取最新的已提交行版本，再加U-Lock返回，不会出现读取旧版本行的情况。
• 若手动指定CURRENTDATA(YES)，FETCH会直接返回游标打开时生成的结果集版本，若目标行在此期间已被修改，执行UPDATE ... WHERE CURRENT OF ...时会直接抛出SQL错误，明确检测到行变更，不会执行无效更新。

关于丢失更新问题的困惑解答 #

你担心的丢失更新场景实际不会触发，核心逻辑如下：

• U-Lock仅和S-Lock兼容，与其他U-Lock、排他锁（X-Lock）互斥：如果有其他事务也需要修改同一行，无论通过普通UPDATE语句还是另一个FOR UPDATE游标修改，都需要申请U-Lock或X-Lock，此时会被你持有行的U-Lock阻塞，直到你完成更新、提交事务释放锁后才能继续执行。
• 阻塞结束后，其他修改事务拿到的是你提交后的最新行版本，不会基于旧值做更新，因此不会出现更新覆盖的问题。仅做只读操作的事务读取旧值不存在修改逻辑，自然也不会触发丢失更新问题。

内容的提问来源于stack exchange，提问作者Monty Burns