SAP Lock Objects, ENQUEUE/DEQUEUE and the Enqueue Server

The SAP lock concept prevents two users or processes from changing the same logical business object concurrently even when work spans multiple dialog steps and database LUWs. A lock object is defined over one or more Dictionary tables/keys. In classic ABAP activation generates enqueue and dequeue function modules. The enqueue server stores logical lock entries centrally so different application servers see the same lock state. Lock modes such as shared/read, exclusive/write and enhanced exclusive control compatibility. The lock key can be generic when trailing fields are initial, which is powerful but can accidentally lock a far larger object set than intended.

Use an application lock before reading data that will later be changed when another session could update the same object during the business transaction. Use the standard lock object supplied by the application whenever one exists; custom locks should model the same business key that the transaction protects. Do not use generic E_TABLE locking as a substitute for a semantic lock object in normal application code. Database locks are appropriate only for the short database transaction itself; they cannot protect a multi-screen SAP business transaction in the same way.

Enqueue locking works with SAP LUWs, update tasks and commits. Locks can be passed to the update owner depending on scope, so they survive from dialog processing until the associated update finishes. SM12 is the primary operational monitor. A foreign lock error is often a valid business-concurrency outcome, not a system failure. RAP managed business objects have framework-managed lock behavior and can use master/etag concepts rather than hand-coding classic lock function calls. ABAP Cloud provides CL_ABAP_LOCK_OBJECT_FACTORY instead of direct generated FM calls.

Two users open the same custom pricing agreement. Without a logical lock, both read version 10, make different edits and save; the second commit silently overwrites the first. A lock object keyed by agreement ID is acquired when change processing begins. The second user receives a foreign-lock message and stays in display/wait mode. The first user's lock is handed through the update scope until commit completes, then released. If support later sees the object permanently locked, SM12 identifies the owner and key before anyone considers deleting it.

The enqueue concept remains fundamental in S/4HANA. SAP S/4HANA Cloud developer extensibility exposes lock objects through CL_ABAP_LOCK_OBJECT_FACTORY and IF_ABAP_LOCK_OBJECT because direct generated ENQUEUE/DEQUEUE function-module usage is not the cloud programming model. Classic on-premise/private-cloud applications still contain generated lock calls extensively. RAP adds its own managed locking semantics on top of the same need for concurrency control.

ABAP/application developers design lock keys, modes and scope. Functional owners define the business object that must be protected. Basis owns enqueue-server availability and SM12 administration, but lock contention caused by application key design belongs to the application team.

SM12 displays current enqueue locks. The SAP LUW/update-task topics explain lock lifetime through commit. ETag/concurrency in OData is complementary optimistic concurrency at the service layer; it does not make backend business locking irrelevant.