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.
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.
Type of Lock |
Lock Mode |
Meaning |
|---|---|---|
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 (E) set by another user on an object that already has a shared lock will be rejected. Every extended exclusive lock (X) will also be rejected. |
Exclusive Locks |
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. For more information, 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.
For more information, see: 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:
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 Enqueue Server. Network communications and process changes are added to this in work processes of other application servers, or when using the standalone enqueue server. Depending on CPU and network load this amounts to a few milliseconds.
Wild Cards
You can use special characters in your lock argument (@). The ‘@’ symbol is used as a wildcard in SAP locks (enqueues). In other words, it can stand for any other character during collision checks.
Note
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.
Locks in ABAP Programs
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 this, you define a lock object in the Data Dictionary and then activate it. Activating it causes the system to generate two function modules: One to lock the object, and one to release it.
More information is available in the following sections of the Data Dictionary documentation:
More Information
You can find more information about how the lock concept works in the following sections: