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.
Lock Server
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.If a lock is to be set in an application running on an instance other than the central instance (for example, on a different host), the lock request is transferred via the local
dispatcher and message server to the dispatcher of the central instance, which then forwards it to the enqueue work process. This process then 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.
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 servers.
The graphic below shows the communication path in a distributed SAP system with one central instance and additional instances.
Enqueue Communication
Locks and SAP Updates
During the course of the transaction, the lock is transferred 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 transferred 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.
SAP Locks and Database Locks
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).
Details on the functions of the lock concept are provided under:
The Owner Concept The Lock Table Lock Collisions Cumulation of Locks Questions and Answers Regarding Locks