Frequently Asked Questions: Lock Concept

The following section contains often-asked questions on the lock concept with the accompanying answers. Most aspects are described in greater detail under Functions of the SAP Lock Concept.

The questions are sorted by topic areas.

Architecture
Programming
Problem Analysis
High Availability
Performance

Architecture

Question	Answer
Where is the lock table?	In the main memory, the shared memory of the enqueue server. If the enqueue server is installed as the enqueue work process, all work processes of this instance have access to the lock table. External application servers execute their lock operations in the enqueue process on the enqueue server. The communication occurs through the relevant dispatcher and the message server. If the Standalone Enqueue Server is used all work processes communicate directly with the enqueue server.
Why is an enqueue work process required in a central AS ABAP system? All work processes have the same access to the shared memory and therefore to the lock table.	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.
Can there already be locks after the startup?	Yes, saved locks inherited by the update task are loaded back into the lock table when the system is started up.
Are the locks in the lock table also set on the database level? If not, database functions could be used to process objects locked in the SAP system?	Locks are not set in the database. The lock table is located in the main memory of the enqueue server. More information: Relationship Between SAP Locks and Database Locks

Programming

Question	Answer
What does the _SCOPE parameter mean? How does the lock owner concept work?	Lock Owners _SCOPE Parameters
How do I find out from the program who owns the open lock? How can use the ENQUEUE program to determine which user currently owns the lock, in order to inform this user?	After the return of the function module `ENQUEUE_...`, the lock owner’s name is displayed in SY-MSGV1.
Can I use special characters in my lock argument (especially the ‘at’sign (@))?	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. More information: 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

Answer

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

Lock Owners

_SCOPE Parameters

How do I find out from the program who owns the open lock? How can use the ENQUEUE program to determine which user currently owns the lock, in order to inform this user?

After the return of the function module ENQUEUE_..., the lock owner’s name is displayed in SY-MSGV1.

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

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.

More information: 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.

Problem Analysis

Question	Answer
What do I do first when problems occur?	Run diagnostic functions: Transaction `SM12` Extras Diagnosis Transaction `SM12` Extras Diagnosis in Update If a problem is reported, back up the trace files `dev_w`, `dev_disp`, and `dev_eq` and check the Syslog.
In the dialog details in transaction SM12, the following message is displayed: `Lock management operation mode` `Internal lock management in same process` What does this mean and what other options are there?	`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 on to an application server that is not an enqueue server, the diagnosis function tells you the name of the enqueue server. Note Each SAP System has exactly one application server that functions as an enqueue server. It maintains the lock table that is located in a shared memory segment. All 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. The behavior is automatically configured. In the default profile DEFAULT.PFL, the parameter line rdisp/enqname =<application server name> tells you which application server is available 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. Enqueue work processes guarantee immediate processing of incoming requests. 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. End of the note.
In the system log, you often find messages like the following: `Enqueue: Previous accumulated waiting time for locks: 2500 seconds.` How do I analyze the problem? Or, is this entry not critical? (Canceled transactions or timeouts were not noted.)	The message gives you information about parallel operation of ABAP programs that is not running properly. The waiting time is displayed that has accumulated since the startup, due to using the WAIT parameters 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.

Question

Answer

What do I do first when problems occur?

Run diagnostic functions:

Transaction SM12 Extras Diagnosis
Transaction SM12 Extras Diagnosis in Update

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

In the dialog details in transaction SM12, the following message is displayed:

Lock management operation mode

Internal lock management in same process

What does this mean and what other options are there?

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 on to an application server that is not an enqueue server, the diagnosis function tells you the name of the enqueue server.

Note Note

Each SAP System has exactly one application server that functions as an enqueue server. It maintains the lock table that is located in a shared memory segment. All 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.

The behavior is automatically configured. In the default profile DEFAULT.PFL, the parameter line rdisp/enqname =<application server name> tells you which application server is available 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.

Enqueue work processes guarantee immediate processing of incoming requests. 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.

End of the note.

In the system log, you often find messages like the following: Enqueue: Previous accumulated waiting time for locks: 2500 seconds. How do I analyze the problem? Or, is this entry not critical? (Canceled transactions or timeouts were not noted.)

The message gives you information about parallel operation of ABAP programs that is not running properly. The waiting time is displayed that has accumulated since the startup, due to using the WAIT parameters 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.

High Availability

Question	Answer
What happens to locks, if the enqueue server is restarted?	In classical enqueue or standalone enqueue without replication, the locks are list if not saved to a backup file on the disk. The locks stored on disk are those that were passed on to the update task during the `COMMIT WORK` after `CALL FUNCTION .. IN UPDATE TASK`. The backup occurs at the time at which the update request was valid (in the `COMMIT WORK`). Each time the enqueue server is restarted, the lock entries stored on the disk are reloaded in 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 of a high availability solution, locks will not be lost if the enqueue server fails or is restarted.
The enqueue server is a single-point-of-failure in the SAP System. Can I guarantee high availability for the Enqueue Server?	To guarantee this you must use the standalone Enqueue Server with the Replication Server. This is described in the documentation Standalone Enqueue Server. SAP Note 524816 contains the prerequisites that must be fulfilled for using the standalone Enqueue Servers with the Replication Server.

Question

Answer

What happens to locks, if the enqueue server is restarted?

In classical enqueue or standalone enqueue without replication, the locks are list if not saved to a backup file on the disk. The locks stored on disk are those that were passed on to the update task during the COMMIT WORK after CALL FUNCTION .. IN UPDATE TASK. The backup occurs at the time at which the update request was valid (in the COMMIT WORK). Each time the enqueue server is restarted, the lock entries stored on the disk are reloaded in 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 of a high availability solution, locks will not be lost if the enqueue server fails or is restarted.

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

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

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

Performance

Question	Answer
How fast are lock operations?	In work processes of the enqueue server, they are several hundred milliseconds. 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.
With a single-processor system as the enqueue server, we have reached X SD benchmark users. Can the number of users be increased by using a multi-processor system (message server on the same machine as the enqueue)? Is the scaling going to be 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?	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. The dispatcher and message server form the bottleneck in the enqueue. Linear scaling can be expected for up to three 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 multiple processors can however, increase the throughput even more.

Question

Answer

How fast are lock operations?

In work processes of the enqueue server, they are several hundred milliseconds. 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.

With a single-processor system as the enqueue server, we have reached X SD benchmark users. Can the number of users be increased by using a multi-processor system (message server on the same machine as the enqueue)? Is the scaling going to be 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?

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. The dispatcher and message server form the bottleneck in the enqueue.

Linear scaling can be expected for up to three 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 multiple processors can however, increase the throughput even more.