Enqueue & Lock Management



Share this article :

• To ensure data consistency within an SAP system, you must ensure that data records cannot be accessed and changed by more than one user at any one time. To do this, the SAP system has its own lock management concept.

• From a database perspective, every dialog step forms a physical and logical unit: the database transaction. The database lock administration can only coordinate this type of database transaction. From an SAP point of view, however, this is not sufficient, because SAP transactions, which are formed from a sequence of logically related work steps that are consistent in business terms, are generally made up of several dialog steps. SAP systems need to have their own lock management.

• This is implemented using the enqueue work process. This also ensures that the platform-independence of the lock management is maintained.

• The SAP lock concept works on the principle that SAP programs make lock entries for data records to be processed in a lock table. Lock entries can only be made if none already exist for the table entries to be locked.

• The enqueue work process manages the logical lock of the SAP transactions in the lock table. The lock table is located in the main memory of the instance with the enqueue work process.

• If a user wants change access to data, the executing dialog work process requests a lock (to do so, the application developer must program this request explicitly). If a dialog request is processed on the enqueue server, the dialog work process can access the lock table directly. It now checks whether a new lock can be generated; that is, whether there is a collision with locks that have already been set. If a lock can be set, the dialog work process creates it and the user (lock owner) is given the lock key. The lock key is kept in the user context in the shared memory.

• If the dialog work process that processes the user request and the enqueue work process are not running on the same instance, these two work processes communicate through the message server. In this case, the lock request is forwarded from the dialog work process to the enqueue work process via the dispatchers and the message server. The enqueue work process now checks whether a lock can be set. If this is possible, the lock is set by the enqueue work process and the lock key transferred to the requesting dialog work process via dispatcher and message server. When the lock is requested, the system checks whether the requested lock conflicts with existing entries in the lock table. If the lock table already contains corresponding entries, the lock request is refused. The application program can then inform the user that the requested operation cannot currently be executed.

• The application developer can choose between different lock modes:
– Write locks (lock mode Exclusive); the lock data can be edited only by one user. The requests for another write lock and another read lock are rejected. A write
lock protects the locked objects against all types of other transactions. Only the same lock owner can set the lock again (cumulate).
– Read locks (lock mode Shared); several users can have read access to the locked data at the same time. The requests for additional read locks are accepted, even if they are from other users. A write lock is rejected.
– Enhanced write locks (lock mode eXclusive noncumulative); while write locks can be successively requested and released by the same transaction, an enhanced
write lock can only be requested once, even by the same transaction. All other requests for locks are rejected.
– Optimistic locks (lock mode Optimistic); optimistic locks respond like read lock at first and can be changed to write locks. An optimistic lock is set if the user
displays the data in change mode. Optimistic locks on the same object do not collide. If the user wants to save the (changed) data, the optimistic lock must be
changed to a write lock (mode E). (This fails if someone set a non-optimistic lock on the object before.) Other optimistic locks on the object are deleted in
the process. Locks set by an application program are either released by the application program itself or by the update program once the database has been changed. Locks that have been passed on to an update work process in this way are also written to a file at operating system level and can therefore be restored if the enqueue server goes down. Transaction SM12 (Tools → Administration → Monitor→ Lock Entries) displays thelocks that are currently set. If a lock has already been inherited to the update process, the backup flag has also been set. Such a lock will also be included in the lock table again after restarting the enqueue server.

• There are basically two ways of deleting locks held by users:
– Ending the user session in the user overview (transaction SM04 or Tools → Administration → Monitor → System Monitoring → User Overview)
– Manually deleting the lock entries in SM12

• The first method (ending the user session) also results in the original lock ownerleaving the transaction and thereby releasing all locks held; the second method
(manually deleting using SM12) merely deletes the lock entry from the lock table. This theoretically enables several users to change the same data records simultaneously.

Related posts

Repeating SAP Canceled Updates
SAP Dialog Instance (Application Server) Installation Steps
Steps to Create and Copy SAP Area Menu
SICF: Logon cookie check failed; repeat logon
© 2018 ITsiti. All Rights Reserved
Powered by KEEM