Locks: Questions and Answers

The following section contains some common questions and answers regarding the lock concept and is intended to act as a quick reference guide. Most aspects are described in greater detail under Functions of the SAP Lock Concept.

Question

What happens to locks when the enqueue server is restarted?

Answer
If they have not been saved to disk in the backup file, they will be lost. 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. The locks are saved to disk 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.

A lock is saved to disk at the point at which the backup flag is set.



If the enqueue replication service is used as part pf a high availability solution, locks will not be lost if the enqueue server fails or is restarted. See next question.

Question

The enqueue server is a single-point-of-failure in the SAP System. Can I guarantee high availability for the Enqueue Server?

Answer
To guarantee this you must use the standalone Enqueue Server with the Replication Server. This is described in the documentationStandalone Enqueue Server.

SAP note 524816 contains the prerequisites that must be fulfilled for using the standalone Enqueue Servers with the Replication Server.

Question
Where is the lock table stored?

Answer
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.

Question
Can locks exist directly after startup?

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

Question
How fast are lock operations?

Answer
In work processes on the enqueue server, a few 100 microseconds. In work processes of external application servers you have to include network communications and process changes. Depending on CPU and network load this amounts to a few milliseconds.

Question
What should I do first if a problem arises?

Answer
Use the diagnosis functions:

sm12 Extras ® Diagnosis and then

sm12 Extras ® Diagnosis in update

If a problem is reported, back up the trace files dev_w*, dev_disp, dev_eq* and check the Syslog.

Question
The following message is displayed in the diagnosis details in SM12:

Lock management operation mode

Internal lock management in same process

What does this message mean and what are the other options?

Answer
"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 SAP 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 SAP 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.

Question
Why is an enqueue work process required in a central system? Don't all work processes have the same access to the shared memory and thus to the lock table?

Answer
Although the enqueue process is not used in a central system, it does not do any harm. Since almost all customers install 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.

Question
Are the locks in the lock table also set at the database level? If not, database functions could be used to process objects locked in the SAP system.

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

Question
Is a lock table built if an enqueue work process is not started on the enqueue server in the instance profile?

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

Question
What does the _SCOPE parameter mean? How does the lock owner concept work?

Answer
See The Owner Concept.

Question
How can I find out who is currently holding the ungranted lock? In other words, how can check the program after an ENQUEUE to determine which use is currently holding the lock so that I can let him or her know?

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

Question
Can I use special characters in my lock argument (especially the ‘at’ sign (@))?

Answer
The ‘at’ symbol is used as a wildcard in SAP locks (enqueues). In other words, it can stand for any other character during collision checks. For example, the parameter value 12345@ locks the quantities 123450 to 123459, 12345a to 12345z, and 12345A to 12345Z, and all other values with any special character in the 6th character position.

This is described in detail in the section Lock Collisions.

In order to prevent the wildcard mechanism from being activated in SAP locks when it is not required, you need to ensure when enqueue function modules are called that key value parameters do not contain any wildcard characters.

If key values that you want to use to lock individual entities do contain wildcard characters, you have to replace the wildcards with different characters before the enqueue is called.

Question
With a single-process system as an enqueue server, we have reached X SD Benchmark users. Can this number be increased by using a multiprocessor system (message server on the same machine as the enqueue server)? Can we assume that scaling is linear (number of CPUs * X SD users)? How many processes are advisable if message servers, dispatchers, one dialog, and two enqueue processes are to run on the system?

Answer
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 server, dispatchers, and enqueue work processes, which means that up to 3 processors can be occupied simultaneously. Dispatchers and message server 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 server, dispatchers, and work processes are occupied simultaneously. Due to asynchronous system processes (for example, syncer), using more processors can further enhance throughput.

Question
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.)

Answer
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.

:roll:
На самом деле, эта документашка совсем не полностью соответствует действительности. Как это часто бывает у САПа.
Точнее, тут все держится на соглашениях. Никто никого (имеются ввиду транзакции) не может заставить соблюдать блокировки. Одна транзакция может лишь ПОРЕКОМЕНДОВАТЬ другим транзакциям не трогать данные, которые она блокировала. Если соглашениям твердо следуют - их не будут трогать. Но на самом деле, этих соглашений не придерживаются даже САПовские программы. Например, эксклюзивный режим блокировки должен запрещать другим транзакциях не только изменение данных, но и их чтение. Покажите мне транзакцию, которая отказывается показать данные, заблокированные эксклюзивно другой транзакцией.

Если хочется совсем озвереть и блокировать на уровне БД, то можно

CALL FUNCTION 'DB_SET_ISOLATION_LEVEL'.
SELECT SINGLE FOR UPDATE * FROM SBTST WHERE K1 = 99.

потом главное не забыть поставить isolation level обратно в uncommited

CALL FUNCTION 'DB_RESET_ISOLATION_TO_DEFAULT'.

Спасибо - не знал об этой возможности.

А бурчу я не потому, что не хочу, чтобы мне показывались эти данные :-). А бурчу на непоследовательность SAP'a.
Cтавить везде по дефолту самый злой режим блокировки ('X'), и самим же забивать на его суровость. :-))
Зачем тогда и придумывать было все эти фишки?

==========================
Exclusive lock: The locked data can only be displayed or edited by a single user. A request for another exclusive lock or for a shared lock is rejected.
Shared lock: More than one user can access the locked data at the same time in display mode. A request for another shared lock is accepted, even if it comes from another user. An exclusive lock is rejected.
Exclusive but not cumulative: Exclusive locks can be requested several times from the same transaction and are processed successively. In contrast, exclusive but not cumulative locks can be called only once from the same transaction. All other lock requests are rejected.

...да, а, например, блокировки, сделанные с параметром _SCOPE = 2, должны сбрасываться при "COMMIT WORK"е, а не при выходе из транзакции.
Не работает.

А разве по выходе из транзакции не происходит commit work или roll back ? Так что по любому , по окончании работы рфс ф.м., программы , транзакции происходит вызов данных событий, по этим событиям и снимается блокировка(окромя апдейт процессинга , блокировка сниамется по его окончании). Для блокирования межпрограмного делаете или свою таблицу в БД или используете export/import to shared memory (если система 6.20 и более).

При выходе из транзакции блокировка снимается по любому. И не в силу присутствия commit work или roll back.
Согласно же документации, при _SCOPE = 1 блокировка снимается по окончанию транзакции, при _SCOPE = 2 - по окончанию Update-процесса, запускаемого при вызове commit work или roll back (то бишь, вроде бы раньше). Есть еще _SCOPE = 3, но о ней я даже не хочу рассуждать :-).

Сорри, про _SCOPE оказался неправ.
Несколько неправильно запускал ФМ IN UPDATE TASK

Господа, не могу вызвать данную функцию.
Кто-н может объяснить что это вообще такое:
ID 'GRANULES' FIELD Seqta_lis-*sys*
Нет такого поля в данной структуре.

Вот код (правда он в объектно-ориентированом контексте):

Добрый день.
Я хотел бы спросить: " А оно Вам зачем?"

Вообще я хотел проверить заблокирован ли документ, и если да то кем.

Далее меня заинтересовала данная оригинальная конструкция Seqta_lis-*sys*.

Seqta_lis - это структура
Тогда *sys* - это должно быть поле.
Но такого поля нет.
И кроме того в отладке конструкция Seqta_lis-*sys* показывается как таблица.
Что за недокументированная такая конструкция?

Прочитал наш любимый хелп.

Т.е., если у нас блокировка устанавливается не в апдейт-таск, то ей чихать на скоуп - время жизни блокировки не превысит времени работы транзакции. Его можно сократить соотв. вызовом ДЕКЬЮ, но в принципе это необязательно - блокировка снимется автоматом при выходе из транзакции.