!--a11y-->
SAP Lock Concept 
You can use this
function to program different types of locks in your SAP programs. They are
programmed in the lock administration. For more information see
Managing Lock
Entries.
You work with SAP locks when you use SAP transactions. In the course of a transaction the system also sets a database lock, which is in place for a much shorter time than the SAP lock. Unlike database locks, an SAP lock can be set across several database LUWs. For more information see Relationship Between SAP Locks and Database Locks.
You can use different types of locks.
The lock mode describes what type of lock it is. The lock modes are listed in the table below.
Locks Modes
Type of Lock |
Lock mode |
Description |
Shared lock |
S (Shared) |
Several users (transactions) can access locked data at the same time in display mode. Requests from further shared locks are accepted, even if they are from different users. 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) |
Whereas exclusive locks can be requested several times by the same transaction and released one by one, an exclusive, non-cumulative lock can only be requested once by the same transaction. Each further lock request will be rejected. |
Optimistic lock |
O (Optimistic) |
Optimistic locks initially behave like shared locks and can be converted into exclusive locks. See Optimistic Locks. |
In a distributed SAP system, one lock server (also known to as the enqueue server) manages the Lock Table. The lock server can run on the central instance or on a stand-alone system. For more information see the Enqueue Server.
During the course
of the transaction, the lock is passed to the
SAP Update System.
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.
For more
information see The Lock Owner
Concept and
Function Modules for
Lock Requests.
The relationship between SAP locks and database locks is explained in section Relationship Between SAP Locks and Database Locks.
The objective here
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 an SAP LUW and a database LUW is described under
Functions of the
Update Task.
A lock remains set until you either call the corresponding DEQUEUE function module, or close the transaction with an implicit DEQUEUE_ALL.
Saved locks inherited by the update task are loaded back into the lock table when the system is started up.
Lock operations last for a few 100 microseconds in work processes in the lock server (see Enqueue Server) In work processes of external application servers you have to include network communications and process changes. Depending on CPU and network load this amounts to a few milliseconds.
You can use special characters in your lock argument (especially the ‘at’ sign (@)). The ‘at’ symbol is used as a wildcard in SAP locks (enqueues). In other words, it can stand for any other character during collision checks (see Lock Collisions).

To prevent the wildcard mechanism from being activated in SAP locks when it is not required, you need to ensure when enqueue function modules are called that key value parameters do not contain any wildcard characters. If key values that you want to use to lock individual entities do contain wildcard characters, you have to replace the wildcards with different characters before the enqueue is called.
If you program an
SAP transaction to change database objects, you have to lock these objects
beforehand to prevent them being accessed by other users or transactions, and
release the objects after they have been changed. To do so, you must define a
lock object in the Data Dictionary, and then activate it (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. For more information see
The Lock Mechanism
in the ABAP Dictionary documentation.
You can find more information about how the lock concept works in the following sections:
Relationship Between SAP Locks and Database Locks
Frequently Asked Questions: Lock Concept
