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 |
Meaning |
|
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) |
A 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 read locks and can be converted into write locks.
See |
See also:
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 that is running on a different computer to the central
instance, the lock request is sent to the dispatcher of the central instance
via the local Dispatcher and Message Server.
The dispatcher of the central instance then forwards the request 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 server.
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 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.
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
(non-continuous) 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