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 enqueue server is restarted, locks will be lost if they have not been saved on the backup file on the hard drive. Those locks that were passed on to the update task during the COMMIT WORK after CALL FUNCTION .. IN UPDATE TASK are stored in this file. The backup file is saved at the time when the update request becomes valid (in the COMMIT WORK). Each time the enqueue server is restarted, the saved lock entries saved are reloaded into 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 central instance. All work processes in the central instance have access to the lock table. External application servers execute their lock operations in the enqueue process on the central instance. The communication occurs through the relevant dispatcher and the message server.
NoteAlthough the enqueue work process is not used in a central (ABAP) system since all work processes have equal access to the shared memory, and hence to the lock table (see figure), the configuration of an enqueue server (parameter rdisp/enqname) and of an enqueue work process (rdisp/wp_no_enq = 1) is mandatory.
If these parameters are not set correctly, the consistency check (transaction SICK) reports an installation error.
End of the note.