You are on page 1of 3

Standalone Enqueue Server

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.

Your SAP system no longer has a central instance in the classical sense (as shown in the graphic above). so that you do not have to implement high availability for the entire central instance.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. The standalone enqueue server. together with the enqueue replication server that runs on another machine is a high availability solution. . Even with AS ABAP you can use the standalone server on its own. In both cases. If the host fails this data is lost and cannot be restored even when the enqueue server is restarted. Features With AS Java the use of the standalone enqueue server is configured by default. you can configure the HA scenario with the enqueue replication server. We therefore recommend that you use the standalone enqueue server. All transactions that have held locks must therefore be reset.

. and high availability does not necessarily have to be provided for. In most cases.SAP System (ABAP) with High Availability Enqueue Server Thanks to the multithreaded architecture of the standalone enqueue server. which on a conventional AS ABAP system is dealt with sequentially by the dispatcher. The I/O load. enqueue request processing and synchronization of the lock table with the replication server can be carried out in parallel. you do not need to use the standalone enqueue server. is distributed across several threads. The work processes of the central instance have direct access to enqueue functions. this makes it possible to process a higher number of enqueue requests. Constraints If your ABAP system has only one instance (classic ABAP central system).