【原】关于 SAP Lock Owner 问题的讨论

在 SAP 事务开始时，始终会创建两个所有者(Owner)并可以请求锁定。

一把锁可以有一个或两个所有者，分别是对话所有者和更新所有者。 可以在 _SCOPE 参数中指定所有者的个数。默认为 2 即 2 个所有者：

要找出当前持有锁的用户，请使用 Function Module ENQUEUE_....

这会将当前持有锁的用户名放入 SY-MSGV1。

• _SCOPE = 1: 只有 dialog owner 才拥有锁。因此锁的生命周期只存在于 dialog transaction 内。

DEQUEUE 调用或事务结束（而不是 COMMIT WORK 或 ROLLBACK WORK）会取消锁定。

• _SCOPE = 2: 该锁仅属于更新所有者 (owner_2)，因此如果调用 CALL FUNCTION 'XXX' IN UPDATE TASK 和 COMMIT WORK，则该锁将由更新任务继承。 当更新事务完成时，锁被释放。也可以在使用 ROLLBACK WORK 将锁定转移到更新之前释放锁定。

注意：除非已调用 CALL FUNCTION '...'IN UPDATE TASK，否则 COMMIT WORK 无效。

• _SCOPE = 3: 该锁属于两个所有者（owner_1 和owner_2）。 换句话说，它结合了两者的行为。 当两个所有者中的最后一个释放该锁时，该锁才将被取消。

ABAP Enqueue Function Module 默认的行为是 _scope = 2.

通过一张图加深理解：

在此示例中，锁对象 A（开发人员之前在 ABAP 字典中创建的）在事务期间通过函数调用 CALL FUNCTION 'ENQUEUE_A' 被锁定。 通过将 _SCOPE 参数设置为 1，锁 A 不会传递到更新进程（它仅属于对话框所有者 E_1）。 该锁由函数调用 DEQUEUE_A 释放，或者最迟在对话事务结束时释放。

随后，请求属于 E_2（更新所有者）（_SCOPE=2）的锁 B 和拥有两个所有者（_SCOPE=3）的锁 C。 当调用 CALL FUNCTION '...' IN UPDATE TASK 时，会生成更新请求。 COMMIT WORK 调用更新过程，锁 B 和 C 的锁和更新所有者继承该过程。 更新结束时，这些锁将被释放。 、、

然而，来自对话所有者的锁C可能随后存在（取决于事务编程）。

如果设置了 _SCOPE=2 的锁，并且在 CALL FUNCTION '...' IN UPDATE TASK 之前调用 COMMIT WORK，则直到此时该锁仍保持为对话锁（在事务 SM12 的界面中显示为黑色）。 此时，还不可能将锁转移到更新工作进程。

仅当调用 CALL FUNCTION '...' IN UPDATE TASK 并执行 COMMIT WORK 时，锁才会稍后传递给更新进程。 然后，在锁管理的详细视图中将其标记为具有备份标志的锁。