Some questions and answers about the SAP ABAP lock mechanism

Lock table location

The Lock Table is located in the main memory (shared memory) of the Enqueue Server.

If the enqueue server is installed as an enqueue worker process, all worker processes of that instance have access to the lock table. The external application server performs its locking operations during the enqueue process on the enqueue server.

The communication between the two is carried out through the relevant dispatcher (dispatcher) and the message server.

If using a standalone enqueue server, all worker processes communicate directly with the enqueue server.

After the server is restarted, is there still a lock record in the main memory?

possible. The lock inherited from the Update task is saved to the storage medium of the ABAP server, and will be reloaded into the lock table when the system is restarted.

After the Enqueue function is called, the system variable SY-MSGV1stores the owner name of the current lock.

@Symbols are used as wildcards in SAP locks (queuing). In other words, it can represent any other character during the lock's conflict checking. For example, the parameter value 12345@locked quantities 123450 to 123459, 12345a to 12345z, 12345A to 12345Z, and all other values ​​with any special character in the 6th character position.

In order to prevent the SAP lock from activating the wildcard mechanism when it is not needed, it is necessary to ensure that the key-value parameter does not contain any wildcards when calling the enqueue function module.

If the key value to be used to lock a single entity does contain wildcards, the wildcards must be replaced with different characters before calling the enqueue function.

Only one application server per SAP system acts as the enqueue server. It maintains a lock table located in the shared memory segment.

All worker processes on the enqueue server have access to the lock table. All worker processes on other application servers delegate their lock requests to a special enqueue worker process on the enqueue server.

This behavior is automatically configured. In the default configuration file DEFAULT.PFL, the parameter line rdisp/enqname =<应用程序服务器名称>tells the developer which application server can be used as the queuing server. When the application server detects that its name matches that of the queuing server, it creates the lock table and all of its worker processes process the queuing request inline. If the application server detects that its name does not match that of the enqueue server, it sends all enqueue requests to the enqueue server.

Queued workflows guarantee that incoming requests are processed immediately. Usually one enqueue process is enough. In large SAP systems with many application servers, a second process may be useful. However, it is not convenient to define more than two enqueue processes. If transaction SM50 CPU shows that only the first enqueued process is being used, the bottleneck is due to something else.

Guess you like

Origin blog.csdn.net/i042416/article/details/132269344