Show TOC

Standalone Enqueue ServerLocate this document in the navigation structure


The enqueue function is not just available in the classical ABAP central instance, it is also available in a standalone server that is not part of AS ABAP. The standalone enqueue server is used in the following scenarios:

  • AS Java provides a locking service based on the enqueue function. The standalone enqueue server, which forms the SCS Instance together with the message server, is used for this.

  • To set up the enqueue service as a high availability solution in AS ABAP, the enqueue service must be removed from the central instance. It is then made available through the standalone enqueue server. Instead of the classic central instance (application server complete with enqueue work process and lock table),you have an SCS instance for the AS ABAP ( ASCS Instance). As with the SCS instance of the AS Java, the message server here is also part of the ASCS instance.

Implementation Considerations

The standalone enqueue server provides the following benefits:

  • The enqueue clients (SAP application servers) and the enqueue server communicate directly, that is, the work process has a TCP connection to the enqueue server. They no longer communicate via the dispatchers and the message server.

  • You can implement the standalone enqueue server as part of the high availability enqueue server solution (with replication server) and thus make the enqueue server breakdown-proof. The procedure to do this is closely linked to the implemented cluster software.


A “classical” SAP system (AS ABAP) contains several single points of failure (SPOF). If these fail, not all of them can simply be restarted on another computer:

The SAP message server can be restarted quickly and easily. While this server is down, the application servers cannot communicate with each other, but no important data is lost.

The SAP database has to be secured by means of database failover solutions.

The SAP central instance (the classical model) is a single point of failure because of the enqueue services that it provides.

Figure 1: SPOFs in the Classical SAP System

The enqueue server holds critical data in the lock table in the main memory: All locks that are currently held by users. If the host fails this data is lost and cannot be restored even when the enqueue server is restarted. All transactions that have held locks must therefore be reset.

We therefore recommend that you use the standalone enqueue server, so that you do not have to implement high availability for the entire central instance. The standalone enqueue server, together with the enqueue replication server that runs on another machine is a high availability solution. Your SAP system no longer has a central instance in the classical sense (as shown in the graphic above).


With AS Java the use of the standalone enqueue server is configured by default. Even with AS ABAP you can use the standalone server on its own. In both cases, you can configure the HA scenario with the enqueue replication server.

Figure 2: SAP System (ABAP) with High Availability Enqueue Server

Thanks to the multithreaded architecture of the standalone enqueue server, enqueue request processing and synchronization of the lock table with the replication server can be carried out in parallel.

The I/O load, which on a conventional AS ABAP system is dealt with sequentially by the dispatcher, is distributed across several threads. In most cases, this makes it possible to process a higher number of enqueue requests.


If your ABAP system has only one instance (classic ABAP central system), and high availability does not necessarily have to be provided for, you do not need to use the standalone enqueue server. The work processes of the central instance have direct access to enqueue functions.