乐趣区

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

退出移动版