SAP ABAP 零碎应用 Collision Check 机制来查看锁申请是否与现有锁抵触。
如果发生冲突，对话事务的用户会收到一条音讯，批示所申请的对象以后已被不同的用户锁定。
留神：对于非对话工作过程（在批量输出中），稍后会再次收回锁定申请。
SAP 官网文档中对 collision check 机制的形容：
There are two steps when checking if a lock request collides with an existing lock: First, the system checks if the lock request collides with an elementary lock in the lock table. If this is the case, the system checks if there is an owner collision. (The same owner may, for example, request a write lock more than once. This is described in Lock Cumulation.)
由此可见，collision check 流程分为两个步骤。
- 零碎查看锁申请是否和 lock table 中的
elementary lock产生了抵触。 - 如果的确产生了抵触，再查看以后 lock request 是否和 lock table 里的条目产生了 owner collision.
之所以要查看 owner collision，是因为同样的 owner 有可能反复提交写锁申请 (write lock request).
如果发生冲突，对话事务的用户会收到一条音讯，批示所申请的对象以后已被其余用户锁定。
对于非对话工作过程（在批量输出中），稍后会再次收回锁定申请。
如果满足以下所有条件，则咱们称两个 Elementary Lock 发生冲突：
- 根本锁（要锁定的表）的名称是雷同的。
- 锁参数：锁参数是雷同的。每个地位的字母都匹配（这里用 @示意的通配符字母对于所有字母都是雷同的）。
- 至多有一个根本锁不处于读锁定状态。
下图是一些具体的例子。
第三个锁申请，因为申请的是读锁，而 lock table 里也是读锁，因而不存在锁抵触的状况。
第四行 lock table 里曾经有 S 即读锁存在，此时试图上一个写锁，E，会失败。