Example: Using the Check Lock Modes 
In addition to lock modes S, E, X and O or R, where the lock is set following a successful collision check, there are also modes U,V, W and C. These are used only to perform the collision check; they do not set any lock. The caller therefore receives the result of whether he or she would have received a lock of the relevant type.
The following correlation applies here:
Lock Mode |
Collision Check for Lock Type |
|---|---|
U |
X |
V |
E |
W |
S |
C |
R (Conversion of an optimistic lock into an E lock) More information: Optimistic Locks |
Procedure
You can use these lock modes to implement a protection for shared locks that prevents a writer “starving”, that is, never being able to set his or her exclusive lock, because there is always at least one shared lock in place.
In the following examples, xxx and yyy are different elementary locks that relate to the same data. This can occur through different database tables with the same fields.
The reader then performs the following operations basically, that is in one lock operation:
V … yyy … ;determines whether a writer wants to set a lock. If a collision occurs, the reader does not do anything else.If there was no collision for the V “lock”:
S … xxx …;locks the object (type S: shared lock) and permits other readers, but no writers.
Note
To do this, you need to use an enqueue function module that contains both elementary locks. You can define a lock object of this type in transaction SE11 (or SE80) from tables with a foreign key relationship.
The lock operations of the writer are as follows (not basic, but rather successive lock operations):
E … yyy …;excludes new readers and other writers… Loop …;waits until the last reader has releasedE … xxx …then sets the exclusive lock.