在 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 时，锁才会稍后传递给更新过程。而后，在锁治理的具体视图中将其标记为具备备份标记的锁。