using lock objects

[Former Member]

hi everyone

i need to work on lock objects. can anyone tell me wat are lock objects and also a program using lock objects plss.

points will be given

thanks in advance

[Former Member]

hi,

Lock objects are use in SAP to avoid the inconsistancy at the time of data is being insert/change into database.

SAP Provide three type of Lock objects.

- Read Lock(Shared Locked)

protects read access to an object. The read lock allows other transactions read access but not write access to

the locked area of the table

- Write Lock(exclusive lock)

protects write access to an object. The write lock allows other transactions neither read nor write access to

the locked area of the table.

- Enhanced write lock (exclusive lock without cumulating)

works like a write lock except that the enhanced write lock also protects from further accesses from the

same transaction.

You can create a lock on a object of SAP thorugh transaction SE11 and enter any meaningful name start with EZ Example EZTEST_LOCK.

Use: you can see in almost all transaction when you are open an object in Change mode SAP could not allow to any other user to open the same object in change mode.

Example: in HR when we are enter a personal number in master data maintainance screen SAP can't allow to any other user to use same personal number for changes.

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.

for sample program check in transaction /ABAPDOCU.

thanks,

raji

[Former Member]

Hi

 Name of the lock object should always start with u2018Eu2019 & next letter has to be u2018Zu2019 or u2018Yu2019.

 Whenever u activate a lock object 2 function modules are generated u2013

- enqueue_<lock object> (it is used to lock)

- dequeue_<lock object> ( it is used for unlock).

Parameters of the function module:

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 You have the following options:

u2022 _SCOPE = 1: Locks or lock releases are not passed to the update program. The lock is removed when the transaction is ended.

u2022 _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.

u2022 _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. The values allowed for this parameter are S (read lock), E (write lock), X (extended write lock), and O (optimistic lock).

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:

u2022 Initial Value: The lock request or lock release is sent directly to the lock server.

u2022 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.

Whenever you have lock mode X (extended write lock), locks should not be written to the local lock container if very many locks refer to the same lock table. In this case, there will be a considerable loss in performance in comparison with direct transmission of locks.

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:

u2022 Initial Value: If a lock attempt fails because there is a competing lock, the exception FOREIGN_LOCK is triggered.

u2022 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

u2022 FOREIGN_LOCKu2019: A competing lock already exists. You can find out the name of the user holding the lock by looking at system variable SY-MSGV1.

u2022 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

 Lock requests and lock releases can be collected in a local lock container and sent together by calling the function module FLUSH_ENQUEUE.

- This has two advantages over sending the lock requests directly:

1. Communications with the lock server are minimized if the lock requests are sent as a group.

2. The collected lock requests are handled as a group, which means that they are only written to the lock table if this is possible for all the individual requests.

The local lock container is emptied if all the collected lock requests can be executed; otherwise its contents remain unchanged.

 The local lock container can be emptied by calling the function module RESET_ENQUEUE. All the collected lock requests or lock releases are deleted. The local lock container is automatically emptied when the corresponding internal session is ended.

 Lock requests and lock releases are managed together in the local lock container. When the collected requests are sent, the lock requests are sent first. The lock releases are sent once all the requested locks have been assigned.

 The lock requests and lock releases are not adjusted in the local lock container. The order in which the individual requests are written in the local lock container is of no importance.

Locks Modes

Type of Lock Lock mode Description

Shared lock S (Shared) Several users (transactions) can access locked 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.

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) Whereas exclusive locks can be requested 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.

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

[Former Member]

Hi Venkat Buddy,

You have finished research on scripts and now lock objects. Good man.

check this link

http://help.sap.com/saphelp_nw04/helpdata/en/a2/3547360f2ea61fe10000009b38f839/frameset.htm

its a good link

and also refer

Go through the link,

http://help.sap.com/saphelp_47x200/helpdata/en/a2/3547360f2ea61fe10000009b38f839/content.htm

Thanks

Nayan

Reward if useful mate.

[Former Member]

Go through the link,

http://help.sap.com/saphelp_47x200/helpdata/en/a2/3547360f2ea61fe10000009b38f839/content.htm

[Former Member]

This message was moderated.

[Former Member]

Hi.

just try this.

http://help.sap.com/saphelp_nw70/helpdata/en/cf/21eea5446011d189700000e8322d00/content.htm

reward if helpful.

[Former Member]

Hi,

Hope you got atmost information from all our friends...

One more thing i would like to tell you is...

To release multiple locks in the program after all your processing and updating you use a function module to release locks..

DEQUEUE_ALL.

this will release all that locks used in the program...

This topic is very vast and even it links to UPDATE MODES if you go through it. as locks are mostly used while updating.

Hope this would be helpful.

Regards

Narin Nandivada.