Collision Check of Locks

Use

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. In the case of non-dialog processes (such as batch input), the lock request is resubmitted later.

Features

The check determining whether a lock request collides with an existing lock is carried out in two steps. First, the system checks whether the lock request collides with an elementary lock in the Lock Table. If this is the case, the system checks whether an owner collision exists. (The same owner can request an exclusive lock more than once, for example. This is described under Cumulation of Locks.)

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. In the case of non-dialog processes (such as batch input), the lock request is resubmitted later.

Check for Collision of Elementary Locks

Two elementary locks collide if all of the following conditions are fulfilled:

·         The name of the elementary lock (table in which the lock is to be set) is the same.

·         The lock argument is the same, or more precisely: the letters in each position are identical (the wildcard symbol (@) is identical to all letters).

·         At least one elementary lock does not have lock mode S (shared lock).

The following graphic contains examples of collisions between a lock request (left) and an existing lock (right).

...

       1.      Exclusive lock ABCD for table TAB1 collides with the existing exclusive lock ABCD for table TAB1.

       2.      Exclusive lock ABCD for table TAB2 does not collide with the existing exclusive lock ABCD for table TAB1 and is accepted because the lock names are different.

       3.      Shared lock ABCD for table TAB1 does not collide with the existing shared lock ABCD for table TAB1  and is accepted because both are shared locks.

       4.      Exclusive lock ABCD for table TAB1 collides with the existing shared lock ABCD for table TAB1

       5.      Exclusive lock AB@@ for table TAB1 collides with the existing exclusive lock ABCD for table TAB1 because @=C and @=D.

       6.      Exclusive lock ABCD for table TAB1 collides with the existing generic exclusive lock AB@@ for table TAB1 because C=@ and D=@.

       7.      Exclusive lock @@CD for table TAB1 collides with the existing exclusive lock AB@@ for table TAB1 because @=A and @=B and C=@ and D=@.

       8.      Exclusive lock @@CDE for table TAB1 does not collide with the existing exclusive lock AB@@ for table TAB1 because the 5th letter in each case differs (E is not equal to _)

If the elementary locks do not collide, the lock request is added to the lock table as a new entry. If the elementary locks do collide, however, the system checks for an owner collision (described in the following section). 

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.

An owner collision exists if one of the following conditions applies to an elementary lock collision:

·        At least one owner is different

·        The owners are identical but at least one lock has mode X (non-cumulative lock, see also SAP Lock Concept)

The following graphic shows examples of these situations, where O_x is an owner different to O_1 and O_2.

...

       1.      No owner is different, no lock in mode X => no collision

       2.      Owner_2 is different => collision

       3.      Owner_1 is different => collision

       4.      Owner_1 is the same but Owner_2 is different => collision

       5.      No owner is different, no lock in mode X => no collision

       6.      No owner is different, but the lock request has mode X => collision

       7.      No owner is different, but the existing lock has mode X => collision

       8.      Owner_1 is different => collision

       9.      Owner_2 is different => collision

An owner collision, therefore, implies an elementary lock collision. Lock requests are only rejected if an owner collision exists.

See also:

Cumulation of Locks

The Owner Concept