Functions of the SAP Lock
Concept 
This section explains how the SAP lock mechanism is implemented. It provides background information that will help you understand and apply the lock management concept. Specific ways of handling SAP locks are described under Managing Lock Entries.
SAP Lock Logic
If the programmer of an SAP transaction wants to make changes to database objects, he or she must first lock the objects, to prevent concurrent access, and then release (unlock) them again.
To do so, he or she must define and activate a lock object in the Data Dictionary (see Lock Objects in the Data Dictionary documentation). Activating a lock object causes the system to generate two function modules: one for locking the object, and one for releasing it. This procedure is described in detail under Lock Mechanism in the ABAP Dictionary documentation.
The lock mode describes what type of lock it is. Possible lock modes are:
Locks Modes
Type of Lock |
Lock mode |
Description |
Shared lock |
S (Shared) |
Different transactions can set shared locks on the same object. An exclusive lock set on an object that already has a shared lock will be rejected. |
Exclusive lock |
E (Exclusive) |
An exclusive lock protects the locked object against all types of locks from other transactions. Only the same lock owner can reset the lock (accumulate). |
Exclusive but not cumulative lock |
X (eXclusive non-cumulative) |
An exclusive non-cumulative lock protects the object against all types of locks. |
Optimistic lock |
O (Optimistic) |
Optimistic locks initially behave like shared locks and can be converted into exclusive locks. See Optimistic Locks. |
See also:
Lock Server and Enqueue Communication
In a distributed SAP system, one lock server (also known to as the enqueue server) manages the lock table. This server runs on the central instance.
There are two different communication models.
· When the stand-alone enqueue server is used or a Java cluster in a SAP Web AS, the ABAP work processes and the Java server processes communicate directly with the enqueue server.
· In the “classical” ABAP system with one central instance and several dialog instances, the lock request passes via the local Dispatcher and the Message Server to the dispatcher of the central instance, which forwards the request to the enqueue work process. The work processes on the central instance have direct access to the lock table functionality. This means that they do not have to send their lock requests via the dispatchers and message server.
The graphic below shows the communication path in a distributed SAP system with one central instance and additional instances.
The enqueue server checks the lock table to determine whether the lock request collides with an existing lock (see also Lock Collisions). If this is the case, the request is rejected. Otherwise, the lock is set and an appropriate entry is made in the lock table.
Locks and SAP Update (SAP Web AS ABAP)
During the course of the transaction, the lock is passed to the SAP update system. This procedure is described in detail under The Owner Concept and Function Modules for Lock Requests. Locks that have been passed to the update system are stored both in the lock table and in a backup file so that they are not lost if the enqueue server fails. The backup flag is then set in lock management.
Locks and SAP Update (SAP Web AS ABAP)
The following graphic shows the relationship between SAP locks and database locks. The objective here, of course, is to minimize the duration of a database lock. In addition, unlike database locks, an SAP lock can exist across several database LUWs. The difference between a SAP LUW and a database LUW is described under Functions of the Update Task.
The top (solid) blue line represents an SAP dialog transaction that comprises three screens (input windows). Each screen corresponds to a database LUW (see Functions of the Update). Once the user has made an input, the database LUW (light blue line) ends.
Once the user has entered his or her input, processing is then resumed by a dialog work process. After the second user input, processing is completed and the dialog section of the SAP LUW is terminated.
The transaction does not have to be processed by the only one dialog work process. At each screen, the dispatcher simply searches for a free work process to handle the processing.
In this example, an SAP lock was requested in the first screen of the transaction. This lock remains in place (upper dark blue line) until the application data has been changed on the database. In other words, in most cases, the lock remains intact until the SAP update has been completed. This does not impair performance, since the lock is not a database lock.
The database lock (lower dark blue line) is only in place during the database LUW in which the changes made in the SAP system are actually updated (see Functions of the Update Task).
Further Information
Details on the functions of the lock concept are provided under:
Questions and Answers Regarding Locks