Start of Content Area

Function documentation SAP Lock Concept  Locate the document in its SAP Library structure


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.


Types of 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


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.

Lock Server and Enqueue Communication

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.

Locks and SAP Update (SAP Web AS ABAP)

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.

SAP Locks and Database Locks (SAP Web AS ABAP)

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.

Life-Span of SAP Locks

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.

Duration of Lock Operations

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.

Wild Cards

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.

Further Information

You can find more information about how the lock concept works in the following sections:

Relationship Between SAP Locks and Database Locks

Enqueue Server

Lock Owners

_SCOPE Parameter

The Lock Table

Collision Check for Locks

Cumulation of Locks

Optimistic Locks

Frequently Asked Questions: Lock Concept


End of Content Area