一位采购员正在修改采购申请，另一位采购员几乎同时打开了同一笔记录。两边都能看到数据，也都认为自己有权修改。真正危险的时刻出现在保存时，后提交的内容可能覆盖前一次修改，或者两个操作各自成功了一半，留下彼此矛盾的业务状态。遇到这种场景，我会想到《仙剑奇侠传 1》里的捆仙绳。它对目标施加定身效果，给施放者留出处理局面的时间。ABAP 里的锁对象也有相近的作用，它让争夺同一业务对象的事务受到约束。这个比喻可以用，但不能照搬。游戏里的妖怪被捆住，仿佛整个人都不能行动。ABAP 锁住一张订单时，受到约束的通常是参与同一套锁定约定的修改程序。它不等于暂停用户、不等于禁止读取，也不等于让数据库里那一行从此无法变化。要把捆仙绳用对，关键在于认清绳子绑住的是谁、什么动作会受阻、什么时候松开，以及有没有程序绕开了这根绳子。游戏资料把捆仙绳描述为可以令妖怪动弹不得的道具；一些版本的道具资料还记载了定身五回合的效果。不同版本的具体数值可以另行区分，本文取它最鲜明的特征来类比，也就是对指定目标施加有时效的行动限制。映射到企业系统，指定目标可以是一张采购申请、一笔付款指令，也可以是一份库存盘点单；受到限制的动作通常是并发修改，而不是所有访问。在经典 ABAP 开发中，最贴近捆仙绳的技术是SAP 锁对象。开发人员在 ABAP Dictionary 中定义锁对象，指定它关联的表以及构成锁键的字段。对象激活后，系统生成对应的ENQUEUE_...和DEQUEUE_...函数模块。程序在准备修改业务对象时调用前者申请锁，在适当时机调用后者释放锁。锁记录由 SAP 的中央锁管理机制协调，所以请求落在不同应用服务器上的两个用户，仍然可以围绕同一业务键发生锁冲突。
