The SAP Lock Concept (BC-CST-EQ)

Purpose
The SAP System is equipped with a special lock mechanism that synchronizes access to data on
the database. The purpose of the lock mechanism is to prevent two transactions from changing
the same data on the database simultaneously.
Implementation Considerations
Locks are defined generically as lock ob!ects in the "ata "ictionary. A lock request is a specific
instance of a lock ob!ect and locks a certain database ob!ect# such as a correction or a table
entry.
Lock entries are usually set and deleted automatically when user programs access a data ob!ect
and release it again.
Integration
The SAP lock mechanism is closely related to the update mechanism in $%& 'Page ()*+. A
description of handling lock ob!ects is provided in the A,AP "ictionary "ocumentation under
Lock -b!ects './t.+.
The A,AP documentation e/plains the key elements of the lock concept with regard to
programming A,AP transactions in the section entitled The $%& Lock 0oncept './t.+.
eatures
1ou can use the Lock 2anagement 'Page *3+ functions 4transaction S2(56 to check and delete
lock entries if the SAP dispatcher# operating system# or network connection fails and the
dispatcher is not able to delete these entries. 7n this case# invalid lock entries remain effective
and block access to the locked data when the system is restarted.
8or a better understanding of the $%& lock concept# please refer to the section entitled 8unctions
of the SAP Lock 0oncept 'Page 99+.
The most important profile parameters for the $%& lock concept are described here 'Page *:+.
1ou can use these parameters to tailor your system resources to your needs.
unctions o! the "#$ Lock Concept
This section e/plains how the $%& mechanism is implemented. 7t provides background information
that will help you understand and apply the lock management concept. The specific options with
regard to handling $%& locks are described under 2anaging Lock .ntries 'Page *3+.
"#$ Lock Logic
7f an $%& transaction is to make changes to database ob!ects# the programmer of the transaction
must lock the ob!ects first to prevent concurrent access and then release them again. To do so#
he or she must define and activate a lock ob!ect in the "ata "ictionary 4see Lock -b!ects './t.+ in
the "ata "ictionary documentation6. Activating a lock ob!ect causes the system to generate two
function modules; one for locking the ob!ect# and one for releasing it. This procedure is described
in detail under Lock 2echanism './t.+ in the A,AP "ictionary documentation.
Lock Ser%er
7n a distributed $%& System# one lock server 4also referred to as the enqueue server6 manages
the lock table 'Page 3<+. This server runs on the central instance.
7f a lock is to be set in an application running on an instance other than the central instance 4for
e/ample# on a different host6# the lock request is transferred via the dispatcher './t.+ and
message server to the dispatcher of the central instance# which then forwards it to the enqueue
work process. This process then checks the lock table to determine whether the lock request
collides with an e/isting lock 4see also Lock 0ollisions 'Page 39+6. 7f this is the case# the request
is re!ected. -therwise# the lock is set and an appropriate entry is made in the lock table.
The work processes on the central instance have direct access to the lock table
functionality. This means that they do not have to send their lock requests via the
dispatchers and message servers.
Locks and "#$ &pdate
"uring the course of the transaction# the lock is transferred to the update in $%& 'Page ()*+. This
procedure is described in detail under The -wner 0oncept 'Page 3(+ and 8unction 2odules for
Lock $equests './t.+. Locks that have been transferred to the update are stored both in the lock
table and in a backup file so that they are not lost if the enqueue server fails. The backup flag is
then set in lock management.
SAP Locks and 'ata(ase Locks
The following graphic shows the relationship between SAP locks and database locks. The
ob!ective here# naturally# is to minimize the duration of a database lock. 7n addition# unlike
database locks# an SAP lock can e/ist across several database L=>. The difference between
SAP L=> and database L=> is described under 8unctions of the =pdate Task 'Page (()+.
The Lock Ta(le
'e!inition
The lock table is a table in the main memory of the enqueue server that records the current locks
in the system. 8or each elementary lock# the table specifies the owner# lock mode# name# and the
fields in the locked table.
&se
The lock table is used to manage locks. .very time the enqueue server receives a lock request#
the system checks the lock table to determine whether the request collides with an e/isting lock
4see Lock 0ollisions 'Page 39+6. 7f this is the case# the request is re!ected. -therwise# the new
lock is written to the lock table.
Lock Collisions
The check to determined whether a lock request collides with an e/isting lock is carried out in two
steps; first# the system checks whether the lock request collides with an elementary lock in the
lock table 'Page 3<+. 7f this is the case# the system checks whether an owner collision e/ists.
4The same owner can request a write lock more than once# for e/ample. This is described under
0umulation of Locks 'Page *)+.6
7f a collision e/ists# the user of the dialog transaction receives a message indicating that the
requested ob!ect is currently locked by a different user. 7n the case of non?dialog processes 4such
as batch inputs6# the lock request is resubmitted later.
Collisions (et)een Elementar* Locks
Two elementary locks collide if all of the following conditions are fulfilled;
_ The name of the elementary lock 4table in which the lock is to be set6 is the same
_ The lock argument is the same# or more precisely; the letters in each position are identical
4the wildcard symbol 4+6 is identical to all letters6
_ At least one element lock does not have lock mode S 4read lock6
7f the elementary locks do not collide# the lock request is added to the lock table as a new entry. 7f
the elementary locks do collide# however# the system checks for an owner collision 4described in
the following section6.
,)ner Collision
7f elementary locks collide# a decision is made whether to accept or re!ect the lock request based
on the owner of the locks 4see The -wner 0oncept 'Page 3(+6.
An owner collision e/ists if one of the following conditions applies to an elementary lock collision;
_ At least one owner is different
_ The owners are identical but at least one lock has mode @ 4e/tended write lock# no
cumulation# see also Lock 2ode './t.+6
Cumulation o! Locks
As described under Lock 2ode './t.+# there are three types of locks;
_ Shared 4read lock6; several transactions can set a read lock simultaneously 4to read data that
is not changed6
_ E/clusive 4write lock6; simultaneous read or write locks for this ob!ect are re!ectedA only the
same owner 4see The -wner 0oncept 'Page 3(+6 can request the lock again. This is referred
to as cumulation.
_ .-clusive# lock that cannot be cumulated 4e/tended write lock6; this lock also can only be
requested once by the same owner.
The type of lock selected is determined by the programmer of the transaction when the lock
ob!ect is created. A lock can be set more than once 4cumulation6# if the name# argument# and lock
mode of the elementary lock are identical. The cumulation counter is incremented by one with
each successive cumulation and reduced by one each time a lock is released. The lock is
released when the counter reaches zero