The system uses this function to check whether a lock request collides with an existing lock. If there is a collision, the user of the dialog transaction receives a message indicating that the requested object is currently locked by a different user. For non-dialog work process (in the batch input), the lock request is made again at a later time.
There are 2 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.)
If there is a collision, the user of the dialog transaction receives a message indicating that the requested object is currently locked by a different user. For non-dialog work process (in the batch input), the lock request is made again at a later time.
If all of the following conditions have occurred, two elementary locks collide:
The name of the elemental lock (table where it is to be locked) is the same.
Lock argument: The lock argument is the same. The letters match in each position (the wildcard letter represented here by @, is the same for all letters).
At least one elemental lock is not in lock mode S (read lock).
The following graphic displays various examples of when a lock request (left) collides with an existing lock (right).
Elemental Lock Collisions — Examples
Exclusive lock ABCD on table TAB1 conflicts with existing exclusive lock ABCD on table TAB1
Exclusive lock ABCD on table TAB2 does not conflict with existing exclusive lock ABCD on table TAB1, and is accepted because the lock name is different.
Shared lock ABCD on table TAB1 does not conflict with existing shared lock ABCD on table TAB1, and is accepted because they are both shared locks.
Exclusive lock ABCD on table TAB1 conflicts with existing shared lock ABCD on table TAB1
Exclusive lock AB@@ on table TAB1 conflicts with existing exclusive lock ABCD on table TAB1, because @=C and @=D applies.
Exclusive lock ABCD on table TAB1 conflicts with existing generic exclusive lock AB@@ on table TAB1, because C=@ and D=@ applies.
Exclusive lock @@CD on table TAB1 conflicts with existing exclusive lock AB@@ on table TAB1, because @=A and @=B and C=@ and D=@ applies.
Exclusive lock @@CDE on table TAB1 conflicts with existing exclusive lock AB@@ on table TAB1, because the fifth letter does not match (E is not _).
If the elementary locks do not collide, the lock request is included as a new entry in the lock table. If the elementary locks do collide, the system checks for an owner collision.
In the case of a collision between elementary locks, whether the lock request is accepted or rejected depends on the Owners.
If one of the following conditions is met when elementary locks collide, an owner collision exists:
At least one owner is different.
The owners are the same, but at least one lock is in mode X (extended exclusive lock, no cumulation).
More information: SAP Lock Concept
The following graphic shows examples of several situations: Here, O_x as an owner is not the same as O_1 and O_2.
Owner Collision — Examples
The owners are the same, no locks are in mode X, therefore there is a collision.
Owner_2 is different, therefore there is a collision.
Owner_1 is different, therefore there is a collision.
Owner_1 is the same, but Owner_2 is different, therefore there is a collision.
The owners are the same, no locks are in mode X, therefore there is a collision.
The owners are the same, but the lock request is in mode X, therefore there is a collision.
The owners are the same, but the existing lock is in mode X, therefore there is a collision.
Owner_1 is different, therefore there is a collision.
Owner_2 is different, therefore there is a collision.
Caution
Therefore, an owner collision implies an elementary collision. The lock request is rejected only if there is an owner collision.