Show TOC

Function documentationCollision Check of Locks Locate this document in the navigation structure

 

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.

Features

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.

Check for Collision of Elementary Locks

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).

This graphic is explained in the accompanying text.

Elemental Lock Collisions — Examples

  1. Exclusive lock ABCD on table TAB1 conflicts with existing exclusive lock ABCD on table TAB1

  2. 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.

  3. 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.

  4. Exclusive lock ABCD on table TAB1 conflicts with existing shared lock ABCD on table TAB1

  5. Exclusive lock AB@@ on table TAB1 conflicts with existing exclusive lock ABCD on table TAB1, because @=C and @=D applies.

  6. Exclusive lock ABCD on table TAB1 conflicts with existing generic exclusive lock AB@@ on table TAB1, because C=@ and D=@ applies.

  7. Exclusive lock @@CD on table TAB1 conflicts with existing exclusive lock AB@@ on table TAB1, because @=A and @=B and C=@ and D=@ applies.

  8. 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.

Check for 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.

This graphic is explained in the accompanying text.

Owner Collision — Examples

  1. The owners are the same, no locks are in mode X, therefore there is a collision.

  2. Owner_2 is different, therefore there is a collision.

  3. Owner_1 is different, therefore there is a collision.

  4. Owner_1 is the same, but Owner_2 is different, therefore there is a collision.

  5. The owners are the same, no locks are in mode X, therefore there is a collision.

  6. The owners are the same, but the lock request is in mode X, therefore there is a collision.

  7. The owners are the same, but the existing lock is in mode X, therefore there is a collision.

  8. Owner_1 is different, therefore there is a collision.

  9. Owner_2 is different, therefore there is a collision.

Caution Caution

Therefore, an owner collision implies an elementary collision. The lock request is rejected only if there is an owner collision.

End of the caution.