How to implement locking in ABAP

Question

Hello everyone,
    I am doing dialog programming and I have a screen that creates some template. When the user opens up the screen it defualts to next available template number to be created (for example if template No 1 exists then it will default to template no 2 so template 2 will be created). But if multiple users open up the screen then it will show template 2 for both of them and I want to avoid this, i.e. I like to implement some locking mechanism so one user opens up the screen that template is locked and the other cannot create the same template. Please share any ideas and suggestions, how I can imeplement this!
Thanks.
Mithun

Answer 1

Hai  Mithun Dha
Lock Objects
The R/3 System synchronizes simultaneous access of several users to the same data records with a lock mechanism. When interactive transactions are programmed, locks are set and released by calling function modules (see Function Modules for Lock Requests). These function modules are automatically generated from the definition of lock objects in the ABAP Dictionary.
Structure of a Lock Object
The tables in which data records should be locked with a lock request are defined in a lock object together with their key fields. When tables are selected, one table (the primary table) is first selected. Further tables (secondary tables) can also be added using foreign key relationships (see also Conditions for Foreign Keys).
Lock Arguments
The lock argument of a table in the lock object consists of the key fields of the table.
The lock argument fields of a lock object are used as input parameters in the function modules for setting and removing locks generated from the lock object definition. When these function modules are called, the table rows to be locked or unlocked are specified by defining certain values in these fields. These values can also be generic. The lock argument fields therefore define which subset of the table rows should be locked.
The simplest case of a lock object consists of exactly one table and the lock argument of the table is the primary key of this table. Several tables can also be included in a lock object. A lock request therefore can lock an entire logical object, and not only a record of a table. Such a logical object can be for example a document comprising an entry in a header table and N entries in a position table.
Locks can also be set from programs in other systems with the corresponding interfaces if the lock object was defined with RFC authorization.
A lock mode can be assigned for each table in the lock object. This mode defines how other users can access a locked record of the table.
Table SFLIGHT in the  flight model contains all the scheduled flights of a carrier. Field SEATSMAX contains the number of seats available. Field SEATSOCC contains the number of seats already booked. If a booking is made for a customer (by a travel agency or sales desk), you must check whether there are enough seats available. The number of seats booked is incremented when the booking is made.
This mechanism must ensure that two sales desks do not make the same booking at the same time and that the flight is not overbooked.
This can be done by creating lock object ESFLIGHT. Only the table SFLIGHT must be included in this lock object. The flight can then be locked (with the function modules generated from the lock object) when booking. If another sales desk also wants to book seats for this flight, the lock will prevent the flight from being overbooked.
Activating a lock object in the ABAP Dictionary automatically creates function modules for setting (ENQUEUE_<lock object name>) and releasing (DEQUEUE_<lock object name>) locks.
The generated function modules are automatically assigned to function groups. You should not change these function modules and their assignment to function groups since the function modules are generated again each time the lock object is activated.
Never transport the function groups, which contain the automatically generated function modules. The generated function modules of a lock object could reside in a different function group in the target system. Always transport the lock objects. When a lock object is activated in the target system, the function modules are generated again and correctly assigned to function groups.
Parameters of the Function Modules
Field Names of the Lock Object
The keys to be locked must be passed here.
A further parameter X_<field> that defines the lock behavior when the initial value is passed exists for every lock field <field>. If the initial value is assigned to <field> and X_<field>, then a generic lock is initialized with respect to <field>. If <field> is assigned the initial value and X_<field> is defined as X, the lock is set with exactly the initial value of <field>.
Parameters for Passing Locks to the Update Program
A lock is generally removed at the end of the transaction or when the corresponding DEQUEUE function module is called. However, this is not the case if the transaction has called update routines. In this case a parameter must check that the lock has been removed.
Parameter _SCOPE controls how the lock or lock release is passed to the update program (see The Owner Concept for Locks). You have the following options:
_SCOPE = 1: Locks and lock releases are not passed to the update program. The lock is removed when the transaction is ended.
_SCOPE = 2: The lock or lock release is passed to the update program. The update program is responsible for removing the lock. The interactive program with which the lock was requested no longer has an influence on the lock behavior. This is the standard setting for the ENQUEUE function module.
_SCOPE = 3: The lock or lock release is also passed to the update program. The lock must be removed in both the interactive program and in the update program. This is the standard setting for the DEQUEUE function module.
Parameters for Lock Mode
A parameter MODE_<TAB> exists for each base table TAB of the lock object. The lock mode for this base table can be set dynamically with this parameter. Valid values for this parameter are S (shared), E (exclusive) and X (exclusive but not cumulative).
The lock mode specified when the lock object for the table is created is the default value for this parameter. This default value can however be overridden as required when the function module is called.
If a lock set with a lock mode is to be removed by calling the DEQUEUE function module, this call must have the same value for the parameter MODE_<TAB>.
Controlling Lock Transmission
Parameter _COLLECT controls whether the lock request or lock release should be performed directly or whether it should first be written to the local lock container. This parameter can have the following values:
Initial value: The lock request or lock release is sent directly to the lock server.
X : The lock request or lock release is placed in the local lock container. The lock requests and lock releases collected in this lock container can then be sent to the lock server at a later time as a group by calling the function module FLUSH_ENQUEUE.
Behavior for Lock Conflicts (ENQUEUE only)
The ENQUEUE function module also has the parameter _WAIT. This parameter determines the lock behavior when there is a lock conflict.
You have the following options:
Initial value: If a lock attempt fails because there is a competing lock, the exception FOREIGN_LOCK is triggered.
X : If a lock attempt fails because there is a competing lock, the lock attempt is repeated after waiting for a certain time. The exception FOREIGN_LOCK is triggered only if a certain time limit has elapsed since the first lock attempt. The waiting time and the time limit are defined by profile parameters.
Controlling Deletion of the Lock Entry (DEQUEUE only)
The DEQUEUE function module also has the parameter _SYNCHRON.
If X is passed, the DEQUEUE function waits until the entry has been removed from the lock table. Otherwise it is deleted asynchronously, that is, if the lock table of the system is read directly after the lock is removed, the entry in the lock table may still exist.
Exceptions of the ENQUEUE Function Module
FOREIGN_LOCK: A competing lock already exists. You can find out the name of the user holding the lock by looking at system variable SY-MSGV1.
SYSTEM_FAILURE: This exception is triggered when the lock server reports that a problem occurred while setting the lock. In this case, the lock could not be set.
If the exceptions are not processed by the calling program itself, appropriate messages are issued for all exceptions.
Reference Fields for RFC-Enabled Lock Objects
The type of an RFC-enabled function module must be completely defined. The parameters of the generated function module therefore have the following reference fields for RFC-enabled lock objects:
Parameters
Reference fields
X_<field name>
DDENQ_LIKE-XPARFLAG
_WAIT
DDENQ_LIKE-WAITFLAG
_SCOPE
DDENQ_LIKE-SCOPE
_SYNCHRON
DDENQ_LIKE-SYNCHRON
All the tables that can be included in a lock object must be linked with  foreign keys. There are a number of restrictions to the valid relationships.
The foreign key relationships of the tables of the lock object must form a tree. The tables are the nodes of the tree. The links of the tree mean is the check table of.
The foreign key fields must be key fields of the foreign key table.
The foreign key relationships defined between the base tables of the lock objects may not have any field that is checked against more than one other field. A field therefore may not occur twice as foreign key field in a relationship and may not be checked against two different fields in two different foreign key relationships.
You must keep one restriction in mind for  multi-structured foreign keys. If a field is assigned to a field that is outside the check table, the table containing this field must be in a sub-tree that contains the check table of this foreign key relationship as a root.
These conditions are always satisfied if the key of the foreign key table is an extension of the key of the check table.
Conditions 2, 3 and 4 are meaningless if the particular foreign key field was excluded from the assignment to the key fields of the check table by  marking it as generic or setting it to a constant. This is also true for multi-structured foreign keys if the foreign key field refers to a table that is not contained in the lock object.
Regards.
Eshwar.