In the main memory (shared memory) of the enqueue server. All work processes on the enqueue server has access to the table. External application servers execute their lock operations in the enqueue process on the enqueue server. Communication in this case takes place via the relevant dispatchers and the message server.

Yes, the saved locks, which were inherited by the update task, are reloaded to the lock table during startup (see first question).

In work processes on the enqueue server, a few 100 microseconds. In work processes on external application servers, the message server communication and 8 process changes are added to this. Depending on the CPU and network load, between approx. 20 (best case) and 80 (typical) milliseconds.

Use the diagnosis functions:

Lock management operation mode

"Internal lock management in same work process" in the diagnosis function means that you are logged onto the enqueue server and your work process can access the lock table straight away. You do not have to delegate enqueue requests to an enqueue process on a remote enqueue server. If you are logged onto an application server that is not an enqueue server, the diagnosis function will provide you with the name of the enqueue server.

Each R/3 System has exactly one application server that functions as an enqueue server. This enqueue server maintains the lock table, which is located in a shared memory segment. All of the work processes on the enqueue server can access the lock table. All work processes on other application servers delegate their enqueue requests to a special enqueue work process on the enqueue server.

This procedure is configured automatically. The parameter line "rdisp/enqname =<application server name>" in the default profile DEFAULT.PFL indicates which application server is currently acting as the enqueue server. When an application server detects that its name matches the name of the enqueue server, it creates the lock table and all of its work processes process enqueue requests inline. If an application server detects that its name does not match the name of the enqueue server, it sends all enqueue requests to the enqueue server.

Work processes of the type "enqueue" guarantee that incoming requests are processed immediately. One enqueue process is usually sufficient. In very large R/3 Systems with many application servers, a second process can be beneficial. However, it is not expedient to define more than two enqueue processes. If the transaction SM50 -> [CPU] shows that only the first enqueue process is being used, the bottleneck is due to something else.

Although the enqueue process is not used in a central system, it does not do any harm. Since almost all customers installs an application server sooner or later, problems will inevitably arise if the enqueue process is missing. For this reason, the enqueue diagnosis function will output an error if an enqueue process has not been configured.

Locks are not set on the database. The lock table is stored in the main memory of the enqueue server.

Yes, because the work processes on the enqueue server process the lock table directly, and not via the enqueue process. The latter is only responsible for lock requests from external application servers.

When the ENQUEUE_... function module is returned, the name of the lock owner is listed in SY-MSGV1.

A significant increase in the enqueue server throughput can be expected by using several processors. The CPU load on the enqueue server is distributed relatively evenly between message servers, dispatchers, and enqueue work processes, which means that up to 3 processors can be occupied simultaneously. Dispatchers and message servers represent the bottleneck with the enqueue.

Linear scaling can be expected for up to 3 processors, even if lock requests are so frequent that message servers, dispatchers, and work processes are occupied simultaneously. Due to asynchronous system processes (for example, syncer), using more processors can further enhance throughput.

The Syslog often contains messages such as "Enqueue: total wait time during locking: 2500 seconds". How should I analyze this problem? Or is the entry not critical? (There are no records of terminations or timeouts.)

The message is output for information purposes only but may indicate parallel processing errors with ABAP programs. The specified wait time is the time that has elapsed since startup due to the use of the WAIT parameter when the enqueue function module was called.

The WAIT parameter enables a lock attempt to be repeated a number of times, for example, so that the update task does not have to be cancelled when a lock is set temporarily by other programs. The work process remains busy between the lock attempts.