VB.net/NetCOBOL系统Btrieve记录锁问题：高负载下文件竞争排查

碰到这种高负载下的Btrieve记录锁定冲突，我之前在类似的COBOL+Pervasive技术栈上处理过，咱们先把问题理清楚，再针对性解决：

背景：系统采用VB.NET做UI层、NetCOBOL实现业务逻辑，基于Pervasive DB访问Btrieve文件。用户负载上升后，处理含相同Item ID的销售订单时频繁出现记录锁定冲突——尽管每个销售订单项的处理都包裹在事务对象中，且父销售订单记录已按规范显式锁定，问题已存在一段时间。

可能的冲突根源 #

• Btrieve锁定粒度与顺序不对：你锁定了父订单，但关联的Item记录可能没被正确锁定，或者不同线程访问Item的顺序乱了，导致死锁/冲突。Btrieve默认可能用页锁，同一数据页里的不同Item会被连带锁定，高负载下冲突概率飙升。
• 事务边界没对齐：如果VB.NET触发了多个NetCOBOL子程序，每个子程序单独开事务，那父订单的锁定可能在某个子事务结束后就释放了，其他线程趁机抢Item记录，引发冲突。
• 显式锁定时机错了：父订单的锁定如果是在订单项处理之后才执行，那Item记录早被别的线程锁了，自然冲突。或者锁定范围没覆盖到Item，等于白锁父订单。
• Pervasive配置没跟上高负载：默认的锁升级阈值、事务隔离级别可能不适合当前的并发量，比如Read Committed级别下，其他线程可以修改未锁定的Item记录，导致冲突。

一步步解决建议 #

1. 先把锁定粒度和顺序掰正 #

• 在NetCOBOL访问Item记录时，强制用记录级显式锁定，别依赖默认页锁。用LOCK RECORD语句指定排他锁（如果要修改），并且所有涉及Item的操作都严格遵循「先锁父订单，再锁Item记录」的顺序——所有线程都按这个来，彻底避免循环等待死锁。
• 检查Item的主键索引：确保Item ID是唯一索引，且索引维护正常，不然Btrieve锁定时会扫描一大片数据页，连带锁一堆无关记录。

2. 把整个订单流程塞进同一个事务 #

• 别只给单个订单项加事务，要把「父订单锁定 → 所有订单项处理 → 提交/回滚」整个流程包裹在同一个NetCOBOL事务里。如果VB.NET调用多个COBOL子程序，要确保这些子程序共享同一个事务上下文，别各自开独立事务。
• 代码里明确用BEGIN TRANSACTION开头，END TRANSACTION结尾，中间的所有操作都在这个事务里，保证父订单和Item的锁定状态一直到事务结束才释放。

3. 调整Pervasive DB的锁定配置 #

• 打开Pervasive Control Center，找到对应的Btrieve文件，把锁定模式从默认的页锁改成记录锁（如果业务允许），或者调高锁升级阈值，避免小范围锁定自动升级成页锁/表锁。
• 试一下把事务隔离级别从Read Committed改成Repeatable Read，这样事务期间Item记录不会被其他线程修改，减少冲突。注意：隔离级别越高性能损耗越大，要做压测平衡。

4. 验证显式锁定的有效性 #

• 在NetCOBOL里加日志，输出父订单锁定的时机、Item锁定的结果，确认锁定确实在订单项处理前完成，并且整个事务期间锁都没丢。
• 单独测试Item锁定：写个小脚本，模拟两个线程同时访问同一个Item ID，看锁定是否生效，有没有冲突，排查是不是锁定语句写错了（比如文件句柄、键值不对）。

5. 高负载下的进阶优化 #

• 试试乐观锁：给Item记录加个版本号字段，更新时先对比版本号，一致才更新，不用长时间锁记录。适合冲突多但实际数据修改冲突少的场景，不过要改业务逻辑。
• 搞个订单处理队列：把相同Item ID的订单请求放进队列，串行处理，彻底避免并发访问。这种方式见效快，但要考虑队列的性能和容错，比如用COBOL的内部队列或者Pervasive的消息队列功能。

内容的提问来源于stack exchange，提问作者Kevin Merrill