The server that administers the Lock Table.
The enqueue server is also known as the lock server. There is only one enqueue server in a distributed SAP system, and it runs on the central instance.
Alternatively, you can use the Standalone Enqueue Server, which runs on a separate instance.
The enqueue server receives a lock request and checks the lock table to determine whether the lock request collides with an existing lock (see Lock Collisions). 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.
To ensure high availability for the lock server, you have to implement the stand-alone enqueue server with the replication server. This is useful, for example, if the lock server is a single-point-of-failure in the SAP system. For more information see Standalone Enqueue Server and SAP note 524816.
When the lock server is restarted, locks will be lost if they have not been saved to disk. The locks that are inherited by the update task when COMMIT WORK is executed after CALL FUNCTION .. IN UPDATE TASK are saved to the disk. They are saved when the update request becomes valid, that is, with 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.
· When the stand-alone enqueue server is used or a Java cluster in a SAP Web AS, the ABAP work processes and the Java server processes communicate directly with the enqueue server.
· In the “classical“ ABAP system with one central instance and several dialog instances, the lock request is sent via the local Dispatcher and Message Server to the dispatcher of the central instance, which then 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.
To increase the throughput of the enqueue server you can use more processors. The CPU load on the enqueue server is distributed evenly between message servers, dispatchers, and enqueue work processes, which means that up to three processors can be occupied simultaneously. The dispatchers and the message server represent the bottleneck with the enqueue.
Linear scaling can be expected for up to three processors, even if lock requests are so frequent that message server, dispatchers, and work processes are occupied simultaneously. Due to asynchronous system processes (for example, syncer), using more processors can further enhance throughput.
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. Communication in this case takes place via the relevant dispatchers 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.
The 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.