Lock Mechanisms in the Database System

The database system automatically sets database locks when it receives change statements
(INSERT, UPDATE, MODIFY, DELETE) from a program. Database locks are physical locks on the
database entries affected by these statements. You can only set a lock for an existing database entry,
since the lock mechanism uses a lock flag in the entry. These flags are automatically deleted in each
database commit. This means that database locks can never be set for longer than a single
database LUW; in other words, a single dialog step in an R/3 application program.

Physical locks in the database system are therefore insufficient for the requirements of an R/3
transaction. Locks in the R/3 System must remain set for the duration of a whole SAP LUW, that
is, over several dialog steps. They must also be capable of being handled by different work
processes and even different application servers.

SAP Locks

To complement the SAP LUW concept, in which bundled database changes are made in a single
database LUW, the R/3 System also contains a lock mechanism, fully independent of database locks, that
allows you to set a lock that spans several dialog steps. These locks are known as SAP locks.

The SAP lock concept is based on lock objects.

Lock objects allow you to set an SAP lock for an entire application object. An application object consists of
one or more entries in a database table, or entries from more than one database table that are linked
using foreign key relationships.

Before you can set an SAP lock in an ABAP program, you must first create a lock object in the ABAP
Dictionary. A lock object definition contains the database tables and their key fields on the basis of which
you want to set a lock. When you create a lock object, the system automatically generates two function
modules with the names ENQUEUE_<lock object name> and DEQUEUE_<lock object name> .
You can then set and release SAP locks in your ABAP program by calling these function modules in a
CALL FUNCTION statement.
These function modules are executed in a special enqueue work process. Within an R/3 System,
enqueue work processes run on a single application server. This server maintains a central lock table for
the entire R/3 System in its shared memory.

Unlike the database, which sets physical locks, the SAP lock mechanism sets logical locks. This means
that

 A locked database entry is not physically locked in the database table.

The lock entry is merely entered as a lock argument in the central R/3 lock table. The lock
argument is made up of the primary key field values for the tables in the lock object. These are
import parameters of the enqueue function module. The lock is independent of database LUWs. It
is released either implicitly when the database update or the SAP transaction ends, or explicitly,
using the corresponding dequeue function module. You can use a special parameter in the
update function module to set the exact point at which the lock is released during the database
update.

 A locked entry does not necessarily have to exist in a database table.

You can, for example, set a lock as a precaution for a database entry that is not written to the
database until the update at the end of the SAP LUW.

 The effectiveness of the locks depends on cooperative application programming.

Since there are no physical locks in the database tables themselves, all programs that use the
same application objects must look in the central table themselves for any locks. There is no
mechanism that automatically prevents a program from ignoring the locks in the lock table.
 1. Lock Objects : Lock objects are use in SAP to avoid the inconsistancy at the time of data
is being insert/change into database.
Simultaneous accessing of same data record by multiple users in SAP system is
synchronized by using a lock mechanism.
Locks can be set and released by calling function modules. These function modules will
be generated automatically from the definition of the so-called lock objects in ABAP/4
Dictionary
Function modules :
Enqueue_<obj name> - to lock the table

dequeue_<obj name> - to release the lock

Technicaly:
When you create a lock object System automatically creat two function module.
1. ENQUEUE_<Lockobject name>. to insert the object in a queue.
2. DEQUEUE_<Lockobject name>. To remove the object is being queued through above FM.

You have to use these function module in your program.

LOCK OBJECT.txt
Check the code here :
Type of Lock Lock mode Description
Shared lock (Read) S (Shared) Several users (transactions) can access locked

Row level data at the same time in display mode. Requests
from further shared locks are accepted, even if
they are from different users. An exclusive lock
set on an object that already has a shared lock
will be rejected.

Shared locks (or read locks) allow you to prevent

data from being changed while you are reading it.
Exclusive lock(Write) E (Exclusive) An exclusive lock protects the locked object
Table Level lock against all types of locks from other transactions.
Only the same lock owner can reset the lock
(accumulate).

Exclusive (write lock): simultaneous shared or

exclusive locks for this object are rejected; only
the same owner (see The Owner Concept) can
request the lock again. This is referred to as
cumulation.

Exclusive locks (or write locks) allow you to

prevent data from being changed while you are
changing it yourself
Exclusive but not X (eXclusive non- Whereas exclusive locks can be requested
cumulative lock cumulative) several times by the same transaction and
released one by one, an exclusive, non-
cumulative lock can only be requested once by
the same transaction. Each further lock request
will be rejected.

In the Exclusive mode detailed above, the same

transaction can reread the data from the same record
as and when required. This mode prevents that. In
other words, this mode locks the record in the table
even against the program requesting the lock.....(!)

1.  EXclusive lock that cannot be cumulated

(extended write lock): this lock also can only
be requested once by the same owner.

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.

In a lock object, you must define the tables in which data records must be locked with a lock request, and
the key fields of these tables. When you select the tables, you must first select the primary table. You can
also add further tables (secondary tables), using foreign key relationships (see Conditions for Foreign
Keys). The following figure shows a primary table and its relations with two other tables (secondary
tables).

For example:

The user goes to VA02 to change a sales order, in this program, a lock is set. You can
see such locks in transaction SM12. If a lock is set, and another user accesses the
same sales order, then they will get a message saying that the sales order is locked.
The ENQUEUE function module is used to set the lock, the DEQUEUE function
module is to release the lock.

If several programs running concurrently all set a shared lock for the same application object in the
system, it can make it almost impossible to set an exclusive lock, since the program that needs to set that
lock will be unable to find any time when there are no locks at all set for that object. Conversely, a single
exclusive lock prevents all other programs from reading the locked object.

At the end of an SAP LUW, you should release all locks. This either happens automatically during the
database update, or explicitly, when you call the corresponding dequeue function module. Locks that are
not linked to a database update are released at the end of the SAP transaction.