Enqueue Server 
The enqueue server (also known as the lock server) is the SAP system component that manages the lock table.
There is only one enqueue server in a distributed SAP system. There are various installation options for this server:
The enqueue servers can be configured as an enqueue work process in an instance. This instance is then known as the central instance. This installation option is used mainly in older ABAP-only systems and in systems that consist of one instance only.
The enqueue server can be installed as part of a separate instance. This is when the standalone enqueue server is used. Together with the message server, this server becomes the SCS instance (SAP, Central Services — AS Java) or the ASCS instance (ABAP Central Services — AS ABAP). This means that this instance is a single point of failure, which can be designed for high availability, together with the enqueue replication server.
Features
The enqueue server receives a lock request and checks the lock table to determine whether the lock request collides with an existing lock. If it does, the enqueue server rejects it. If it does not collide, the enqueue server sets the lock and makes the entry in the lock table.
Caution
When the lock server is restarted, locks will be lost if they have not been saved to disk. The locks stored on disk are those that were passed on to the update task during the COMMIT WORK after CALL FUNCTION .. IN UPDATE TASK. The backup occurs at the time at which the update request was valid (in the COMMIT WORK). Each time the enqueue server is restarted, the lock entries saved on the disk are reloaded to the lock table.
If the enqueue replication service is used as part of a high availability solution, locks will not be lost if the enqueue server fails or is restarted.
Communications Model
The communications model depends on the chosen installation option.
When the stand-alone enqueue server is used in an SCS or ASCS instance, the ABAP work processes and the Java server processes communicate directly with the enqueue server.
In a "classical" ABAP system with a central instance and multiple dialog instances, the lock request is passed thorugh the dispatcher and the message server to the dispatcher of the central instance, which forwards the request to the enqueue work process. The work processes on the central instance have direct access to the lock table functions. This means that they do not have to send their lock requests via the dispatchers and message server.
The graphic below shows the communication path in a distributed SAP system with one central instance and additional instances.
"Classical" Central Instance with Enqueue Work Process
The lock table is located in the main memory (shared memory) of the lock server. All work processes in the lock server have access to the lock table. External application servers execute their lock operations in the enqueue process on the lock server. The communication occurs through the relevant dispatcher and the message server.
The work processes on the lock server use the lock table directly, and not via the enqueue process. Therefore the lock table is still set up, even when no enqueue work process is started on the lock server in the instance profile. The enqueue process is only responsible for lock requests from external application servers.
NoteThe enqueue work process is not supported in central (ABAP) systems, since all work processes have equal access to the shared memory and therefore to the lock table too (see graphic). However, if you want to add an application server later, you will need the enqueue server. For this reason we recommend you use the enqueue server from the start.
The enqueue diagnosis function outputs an error if an enqueue process has not been configured.
End of the note.