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.


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. A request for another shared lock is accepted, even if it comes from another user. 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)

Exclusive locks can be requested several times from the same transaction and are processed successively. In contrast, exclusive but not cumulative locks can be called only once from 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 NetWeaver 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 NetWeaver 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. Furthermore, an SAP lock can be valid over several database LUWs, but a database lock cannot. The difference between an SAP LUW and a database LUW is described under Features of the Update.

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.

More 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 Parameters

Lock Table

Collision Check of Locks

Cumulating Locks

Optimistic Locks

Example: Infinite Transaction with Update

Frequently Asked Questions: Lock Concept