SAP Lock Types

The concept of locks is closely related to the concept of transaction isolation. Transaction isolation makes sure that two simultaneously running transactions do not affect each other. Transaction isolation levels are realized by setting locks on read or changed rows in a database table. Databases provide multiple isolation levels that determine how strong the isolation is between two simultaneously running transactions.

Shared lock - S (Shared)
Several users (transactions) can access 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 set on an object that already has a shared lock will be rejected.

Exclusive lock - E (Exclusive)
An exclusive lock protects the locked object against all types of locks from other transactions. Only the same lock owner can reset the lock (accumulate).

Exclusive but not cumulative lock - X (eXclusive non-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. Each further lock request will be rejected.

Optimistic lock - O (Optimistic)
Optimistic locks initially behave like shared locks and can be converted into exclusive locks

The components include:
· The dialog work process that executes a transaction
· The update work process that inherits the locks
· The database
· The Enqueue Server that administers the locks in the Lock Table.

To improve the clarity of the graphic, the enqueue server is not shown.
The duration of the SAP LUW and of the SAP lock is shown on the left.

The dialog work process executes an SAP dialog transaction that comprises three screens (input windows). Each screen corresponds to a database LUW. Once the user has made an input, the database LUW ends.

Once the user has entered his or her input, processing is then resumed by a dialog work process. After the second user input, processing is completed and the dialog section of the SAP LUW is terminated.

The transaction does not have to be processed by the one dialog work process only. For each screen, the dispatcher simply searches for a free work process to handle the processing.

In this example, an SAP lock is requested on the first screen of the transaction. This exists until the application data has been changed in the database, that is, in most cases, until the SAP update is completed. This does not impair performance, since the lock is not a database lock.
The database lock exists only for the duration of the database LUW, in which the changes made in the SAP system are actually updated.