Lock Object

[Former Member]

Hi,

How do I create a Lock Object on a table.

Can I obtain an exclusive lock on the following

1) the whole table

2) on a single record.

Regards,

Balaji.

[seshatalpasai_madala]

Hi,

You can create it from SE11.

Yes you can obtin exclusive lock.

When you use ENQUEUE_LOCK_OBJECT Function module just mention X as the valye for exclusive lock.

1) YES.

2) YES.

Check the thread for more

Regards,

Sesh

[Former Member]

Check with below links :

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

Thanks

Seshu

[Former Member]

hi

Please find the documentation below .

The SAP Lock Concept

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 objects" in the Data Dictionary. A lock entry is a specific instance of a lock object and locks a certain database object, such as a correction request or a table entry.

Lock entries are usually set and deleted automatically when user programs access a data object and release it again.

Functions of the SAP Lock Concept

This section explains how the SAP lock mechanism is implemented. It provides background information that will help you understand and apply the lock management concept. Specific ways of handling SAP locks are described under Managing Lock Entries.

SAP Lock Logic

If the programmer of an SAP transaction wants to make changes to database objects, he or she must first lock the objects, to prevent concurrent access, and then release (unlock) them again.

To do so, he or she must define and activate a lock object in the Data Dictionary in the Data Dictionary documentation). Activating a lock object causes the system to generate two function modules: one for locking the object, and one for releasing it.

The lock mode describes what type of lock it is. Possible lock modes are:

Locks Modes

Type of Lock Lock mode Meaning

Shared lock S (Shared) Different transactions can set shared locks on the same object. An exclusive lock set on an object that already has a shared lock will be rejected.

Exclusive lock E (Exclusive) A 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) An exclusive non-cumulative lock protects the object against all types of locks.

Optimistic lock O (Optimistic) Optimistic locks initially behave like read locks and can be converted into write locks.

Lock Server

In a distributed SAP system, one lock server (also known to as the enqueue server) manages the lock table. This server runs on the central instance.

If a lock is to be set in an application that is running on a different computer to the central instance, the lock request is sent to the dispatcher of the central instance via the local Dispatcher and Message Server. The dispatcher of the central instance then forwards the request to the enqueue work process. This process then checks the lock table to determine whether the lock request collides with an existing lock. If this is the case, the request is rejected. Otherwise, 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 server.

The graphic below shows the communication path in a distributed SAP system with one central instance and additional instances.

Enqueue Communication

Locks and SAP Updates

During the course of the transaction, the lock is passed to the SAP update system. This procedure is described in detail under The Owner Concept and Function Modules for Lock Requests. Locks that have been passed to the update system 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 Database Locks

The following graphic shows the relationship between SAP locks and database locks. The objective here, of course, is to minimize the duration of a database lock. In addition, unlike database locks, an SAP lock can exist across several database LUWs. The difference between a SAP LUW and a database LUW is described under Functions of the Update Task.

The top (non-continuous) blue line represents an SAP dialog transaction that comprises three screens (input windows). Each screen corresponds to a database LUW. Once the user has made an input, the database LUW (light blue line) ends.

Once the user has entered his or her input, processing is then resumed by a dialog work process. After the second user input, processing is completed and the dialog section of the SAP LUW is terminated.

The transaction does not have to be processed by the only one dialog work process. At each screen, the dispatcher simply searches for a free work process to handle the processing.

In this example, an SAP lock was requested in the first screen of the transaction. This lock remains in place (upper dark blue line) until the application data has been changed on the database. In other words, in most cases, the lock remains intact until the SAP update has been completed. This does not impair performance, since the lock is not a database lock.

The database lock (lower dark blue line) is only in place during the database LUW in which the changes made in the SAP system are actually updated.

The Owner Concept

At the start of an SAP transaction, two owners are always created and can request locks.

An owner is identified by his or her owner ID, as described in the section entitled The Lock Table.

A lock can have one or two owners. The ABAP programmer uses the _SCOPEparameter to define this (see below).

The diagram below shows an example of an SAP LUW from a lock perspective.

At the start of the dialog transaction, the system creates two lock owners: the dialog owner Owner_1 and the update owner Owner_2.

During the course of the transaction, Owner_1 requests a lock, as does Owner_2 slightly later. When the update task is called, the lock and Owner_2 are inherited by the update task. An update work process is started with two owners, in the same way as a dialog work process, and then has three owners until the update is completed. All of the locks are released with an implicit DEQUEUE_ALL at the end of the update, at the latest.

The _SCOPE Parameter

The application programmer uses this parameter to determine which of the two owners should actually own the lock. _SCOPE can have the values 1, 2, or 3:

SCOPE = 1 The lock belongs to owner1 only and therefore only exists in the dialog transaction. The DEQUEUE call or the end of the transaction, not COMMIT WORK or ROLLBACK WORK, cancels the lock.

SCOPE = 2 The lock belongs to owner2 only. Therefore, the update inherits the lock when CALL FUNCTION ‘…‘ IN UPDATE TASK and COMMIT WORK are called. The lock is released when the update transaction is complete. You can release the lock before it is transferred to the update using ROLLBACK WORK. COMMIT WORK has no effect, unless CALL FUNCTION ‘…‘ IN UPDATE TASK has been called.

SCOPE = 3 The lock belongs to owner1 and owner_2. In other words, it combines the behavior of both. This lock is canceled when the last of the two owners has released it.

The following diagram shows the locks during the course of an SAP LUW in conjunction with the _SCOPE parameter. The diagram also shows how long the SAP locks are active (these are not the actual database locks.

The lock remains in place until either the relevant DEQUEUE function module is called or (as shown in the diagram) the transaction is completed with an implicit DEQUEUE_ALL.

During the course of the transaction in this example, the lock object A (which was created previously by the programmer in the ABAP Dictionary) is locked by the function call CALL FUNCTION 'ENQUEUE_A'. Since the SCOPEparameter is set to 1, the lock A is not forwarded to the update task (it belongs to the dialog owner E1 only) and, therefore, is released with the function call DEQUEUE_A or, at the latest, at the end of the dialog transaction.

Later, the lock B, which belongs to E_2 (the update owner) ( _SCOPE=2), and the lock C, which has two owners ( _SCOPE=3), are requested. The CALL FUNCTION '…' IN UPDATE TASK generates an update request. At COMMIT WORK, the update task is called and inherits the locks and the update owner of locks B and C. These locks are released when the update is completed. Lock C of the dialog owner, however, may exist longer (depending on how the transaction is programmed).

Dialog locks A and C remain in place until the end of the dialog transaction.

If a lock is set with _SCOPE=2, and the COMMIT WORK is called before the CALL FUNCTION ‘…‘ IN UPDATE TASK, the lock remains in place as a dialog lock until this point in time (displayed in black in the overview screen of transaction SM12). At this point in time, it is not yet possible to transfer the lock to an update work process.

Only once CALL FUNCTION ‘…‘ IN UPDATE TASK and COMMIT WORK are called at a later point in time is the lock transferred to the update process. It is then displayed in the overview screen of SM12.

The Lock Table

Definition

The lock table is a table in the main memory of the enqueue server that records the current locks in the system. For each elementary lock, the table specifies the owner, lock mode, name, and the fields in the locked table.

Use

The lock table is used to manage locks. Every time the enqueue server receives a lock request, the system checks the lock table to determine whether the request collides with an existing lock. If this is the case, the request is rejected. Otherwise, the new lock is written to the lock table.

Structure

Each elementary lock corresponds to a data record in the lock table.

The structure of the lock entries is shown below (lock mode X, E, S, or O).

The individual fields have the following meaning:

Field Contents and meaning

Owner_1 Owner id and cumulation counter of owner_1: the ID contains the computer name, the work process, and a timestamp. It is also used to identify the SAP LUW. The cumulation counter specifies how often the owner has already set this elementary lock.

Owner_2 The above applies here to owner_2

Backup Id Backup Id (index indicating where the lock entry is stored in the backup file) and backup flag (0 (no backup) or 1 (backup)).

Elementary lock Lock mode S (Shared lock, read lock)O (Optimistic lock)E (Exclusive lock, write lock)X (eXclusive lock, extended write lock, cannot be cumulated)

Name Name of the database table in which fields are to be locked

Argument Locked fields in the database table (linked key fields, can also contain wildcards)

Lock Collisions

The check to determine whether a lock request collides with an existing lock is carried out in two steps: first, the system checks whether the lock request collides with an elementary lock in the lock table. If this is the case, the system checks whether an owner collision exists. (The same owner can request a write lock more than once, for example.)

If a collision exists, the user of the dialog transaction receives a message indicating that a different user currently locks the requested object. In the case of non-dialog processes (such as batch input), the lock request is resubmitted later.

Collisions Between Elementary Locks

Two elementary locks collide if all of the following conditions are fulfilled:

1. The name of the elementary lock (table in which the lock is to be set) is the same

2. The lock argument is the same, or more precisely: the letters in each position are identical (the wildcard symbol (@) is identical to all letters)

3. At least one element lock does not have lock mode S (shared lock)

The following graphic contains examples of collisions between a lock request (left) and an existing lock (right).

1. Exclusive lock ABCD for table TAB1 collides with the existing exclusive lock ABCD for table TAB1

2. Exclusive lock ABCD for table TAB2 does not collide with the existing exclusive lock ABCD for table TAB1 and is accepted because the lock names are different

3. Shared lock ABCD for table TAB1 does not collide with the existing shared lock ABCD for table TAB1 and is accepted because both are shared locks

4. Exclusive lock ABCD for table TAB1 collides with the existing shared lock ABCD for table TAB1

5. Exclusive lock AB@@ for table TAB1 collides with the existing exclusive lock ABCD for table TAB1 because @=C and @=D.

6. Exclusive lock ABCD for table TAB1 collides with the existing generic exclusive lock AB@@ for table TAB1 because C=@ and D=@.

7. Exclusive lock @@CD for table TAB1 collides with the existing exclusive lock AB@@ for table TAB1 because @=A and @=B and C=@ and D=@.

8. Exclusive lock @@CDE for table TAB1 does not collide with the existing exclusive lock AB@@ for table TAB1 because the 5th letter in each case differs (E is not equal to _)

If the elementary locks do not collide, the lock request is added to the lock table as a new entry. If the elementary locks do collide, however, the system checks for an owner collision (described in the following section).

Owner Collision

If elementary locks collide, a decision is made whether to accept or reject the lock request based on the owner of the locks.

An owner collision exists if one of the following conditions applies to an elementary lock collision:

1. · At least one owner is different

2. · The owners are identical but at least one lock has mode X (non-cumulative lock)

The following graphic shows examples of these situations, where O_x is an owner different to O_1 and O_2.

1. 1. No owner is different, no lock in mode X => no collision

2. 2. Owner_2 is different => collision

3. 3. Owner_1 is different => collision

4. 4. Owner_1 is the same but Owner_2 is different => collision

5. 5. No owner is different, no lock in mode X => no collision

6. 6. No owner is different, but the lock request has mode X => collision

7. 7. No owner is different, but the existing lock has mode X => collision

8. 8. Owner_1 is different => collision

9. 9. Owner_2 is different => collision

An owner collision, therefore, implies an elementary lock collision. Lock requests are only rejected if an owner collision exists.

Cumulation of Locks

As described under Lock Mode, there are three types of locks:

1. Shared lock: several transactions can set a shared lock simultaneously (to read data that is not changed)

2. Exclusive (write lock): simultaneous shared or exclusive locks for this object are rejected; only the same owner can request the lock again. This is referred to as cumulation.

3. EXclusive lock that cannot be cumulated (extended write lock): the same owner also can only request this lock once.

The programmer of the transaction determines the type of lock selected when the lock object is created.

A lock can be set more than once (cumulation), 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.

The following graphic illustrates how locks are cumulated.

1. 1. The lock request is accepted and written to the lock table. The cumulation counter of the dialog owner Owner_1 is 0. The counter of update owner Owner_2 is 1.

2. 2. The lock request is also accepted. The cumulation counter of dialog owner Owner_1 is still 0 (because SCOPE was set to 2); the counter of update owner Owner2 is now 2.

3. 3. This time, SCOPEis set to 1. In other words, the cumulation counter of dialog owner Owner1 is increased to 1 and that of update owner Owner_2 remains 2.

4. 4. This time SCOPE=3, that is, the lock has two owners. The cumulation counter of dialog owner Owner1, therefore, is increased to 2 and that of Owner_2 is increased to 3.

Optimistic Locks

Purpose

In business applications an increasing number of dialogs are offered, in which data is displayed in change mode, but the likelihood that this data will be changed is not high. If data is accessed simultaneously by different users, a locking procedure must guarantee consistent data changes.

The SAP Lock Concept (enqueue) used for locking in ABAP programs up to now has offered only pessimistic locking. This works well when the likelihood is high that data will be changed, but as described above, it does have limitations when data is accessed simultaneously. At any given point of time data can be displayed as changeable only in one of several parallel dialogs.

For this reason there is a need for an optimistic locking procedure in ABAP programs. Optimistic locking enables data to be changed in all parallel dialogs. The business application, however, must be aware that the data originally displayed may already have changed before the user’s own changes take effect. The locking procedure must be able to detect this case, so that the business application has the possibility to pursue a conflict solution strategy.

New Lock Mode, O

Now, the lock mode O is offered, in addition to the familiar lock modes S, E and X.

An optimistic lock (mode 0) is set, if the user displays data in change mode. Optimistic locks on the same object cannot collide. If the user wants to save the (changed) data, the optimistic lock has to be converted into an exclusive lock (mode E). (This does not work, if beforehand another user has set a non-optimistic lock on the object). This procedure deletes other optimistic locks on the object.

How Optimistic Locks Work

Purpose

What distinguishes optimistic locks from other locks is that competing optimistic locks are at first compatible with each other and do not exclude each other. If there is a lock collision, it will not be verified until later. For the lock owner a lock collision manifests itself in an external change (not made by the lock current user) to the lock, whereby the optimistic lock becomes invalidated.

Process Flow

With optimistic locks data is changed in two phases:

Phase 1:

1. Check to verify that the optimistic lock can be set, that is, there is no external exclusive lock.

2. Optimistic lock is set

3. Data is read

The lock does not protect against external changes to data, but it does help to identify them.

Phase 2:

This phase starts if the data is to be changed. The prerequisite is that the original read data has not been changed. The process steps are:

2. ...

1. Consistency of read data and optimistic lock is checked.

2. Check to verify that the conversion of the optimistic lock to an exclusive lock will not collide with an existing lock.

3. The change is circulated to other owners of optimistic locks. Invalidating the external optimistic locks circulates the change.

4. Optimistic lock is converted into an exclusive lock.

5. The change itself is executed and becomes visible to all.

6. The lock is released.

Steps 1-4 must be completed in an atomic flow – this means either all the steps must be carried out, or none at all. Once the data has been changed, in transactions processed by other users phase 2 cannot be continued following phase 1. Instead, a conflict solution strategy must be pursued.

The graphic below shows the process flow:

Possible conflict scenarios:

1. · The user’s attempt to set the optimistic lock fails, because the object has already been exclusively locked by another owner (or locked non-cumulatively by the same owner). The result is the user cannot access the change mode.

2. · The optimistic lock has been set, but when the user tries to save the (changed) data, it emerges that another optimistic lock has already been converted into an exclusive lock. In this process the optimistic lock has been removed from this transaction.

3. · The optimistic lock is still valid, but an external read lock (S), or an exclusive lock that the user has inherited, exists, which would collide with the O lock when it is converted into an E lock.

Optimistic Lock Conflicts

With regard to collisions a lock of type O behaves like a shared lock (S). This means, it collides with existing E and X locks.

If an exclusive lock belonging to another owner exists, the optimistic lock cannot be set. It is irrelevant whether the write lock is a conventional E lock or a converted optimistic lock.

Optimistic locks belonging to different owners are compatible with one another. The first owner who converts the optimistic lock into an exclusive lock can actually change the data. The other optimistic locks become invalidated (deleted from the lock table). If you try to change them, the exclusive lock cannot be set.

Programming with Optimistic Locks

Programming with optimistic locks is not yet supported in the Data Dictionary. You have to request the locks, as shown in the example program below:

There are the new modes O and R for the ENQUEUE function modules.

Note that the following program displays the calls only. If you want to program optimistic locks in larger applications, you should collect the lock calls together in a subprogram. Then the calls will not be distributed throughout the entire program.

*&----

---

*& Report DEMO_OPT_ENQUEUE&*&----

---

*& Demo program for optimistic locks&& Besides the old lock modes& - Non cumulative lock Mode = 'X'& - Exclusive lock Mode = 'E'& - Shared lock Mode = 'S'&& a new lock mode is introduced& - Optimistic lock Mode = 'O'& - Mode 'R' for promoting an 'O' lock into an 'E' lock& Mode 'R' does not appear in the lock table&& See MODE_xxx-Parameter of the ENQUEUE_xxx FMs&& An optimistic lock is similar to a shared lock 'S'& The differences are the following:&& - it can be promoted to an exclusive lock (mode 'E'),& if there is no collision& The promotion of n optimistic lock collides with& - a shared lock 'S' which didn't collide with the 'O' lock& but collides with the resulting 'E' lock& - an own lock becomes a foreign lock due to passing it to the& update&& - The successful promotion of an optimistic lock to an exclusive lock& deletes all foreign optimistic locks which collide with the& generated 'E' lock.&& - the optimistic lock can get lost due to the promotion of a& foreign 'O' lock (see above).&& Optimistic locks are compatible to the known lock modes.& Programs using ordinary pessimistic locks can coexist with programs& that switched to optimistic locking and use the same& Lock Objects and Enqueue function modules.& You don't need to switch all programs at the same time& Please take care of side effects!&& The existing ENQUEUE_xxx and DEQUEUE_xxx function modules can also& be used for optimistic locks.&*&----

---

• REPORT DEMO_OPT_ENQUEUE. DATA: lock_mode_opt type enqmode value 'O'.DATA: lock_mode_excl type enqmode value 'E'.DATA: lock_mode_opt_to_excl type enqmode value 'R'. *----------------------------------------------------------------------

• Set optimistic lock.* The operation is successful when there is no collision with foreign* 'E' and 'X' locks.*----------------------------------------------------------------------

CALL FUNCTION 'ENQUEUE_ENQ_SFLIGHT' EXPORTING MODE_SFLIGHT = lock_mode_opt EXCEPTIONS FOREIGN_LOCK = 1 SYSTEM_FAILURE = 2 OTHERS = 3. IF SY-SUBRC <> 0. MESSAGE ID SY-MSGID TYPE SY-MSGTY NUMBER SY-MSGNO WITH SY-MSGV1 SY-MSGV2 SY-MSGV3 SY-MSGV4.ENDIF. *----

---

• Promote optimistic lock into exclusive lock.* The operation is successful, if* - the own 'O' lock still exists* - there is no collision of the new 'E' lock with foreign locks*----------------------------------------------------------------------

CALL FUNCTION 'ENQUEUE_ENQ_SFLIGHT' EXPORTING MODE_SFLIGHT = lock_mode_opt_to_excl EXCEPTIONS FOREIGN_LOCK = 1 SYSTEM_FAILURE = 2 OTHERS = 3. IF SY-SUBRC <> 0. MESSAGE ID SY-MSGID TYPE SY-MSGTY NUMBER SY-MSGNO WITH SY-MSGV1 SY-MSGV2 SY-MSGV3 SY-MSGV4.ENDIF. *----

---

• Release exclusive lock*----

-

---

CALL FUNCTION 'DEQUEUE_ENQ_SFLIGHT' EXPORTING MODE_SFLIGHT = lock_mode_excl.

Locks: Questions and Answers

The following section contains some common questions and answers regarding the lock concept and is intended to act as a quick reference guide.

Question

What happens to locks when the enqueue server is restarted?

Answer

If they have not been saved to disk in the backup file, they will be lost. The locks that are inherited by the update task when COMMIT WORK is executed after CALL FUNCTION .. IN UPDATE TASK are saved to the disk. The locks are saved to disk when the update request becomes valid, that is, with the COMMIT WORK. Each time the enqueue server is restarted, the lock entries saved on the disk are reloaded to the lock table.

A lock is saved to disk at the point at which the backup flag is set.

If the enqueue replication service is used as part pf a high availability solution, locks will not be lost if the enqueue server fails or is restarted. See next question.

Question

The enqueue server is a single-point-of-failure in the SAP System. Can I guarantee high availability for the Enqueue Server?

Answer

To guarantee this you must use the standalone Enqueue Server with the Replication Server. This is described in the documentation Standalone Enqueue Server.

SAP note 524816 contains the prerequisites that must be fulfilled for using the standalone Enqueue Servers with the Replication Server.

Question

Where is the lock table stored?

Answer

In the main memory (shared memory) of the enqueue server. All work processes on the enqueue server has access to the table. External application servers execute their lock operations in the enqueue process on the enqueue server. Communication in this case takes place via the relevant dispatchers and the message server.

Question

Can locks exist directly after startup?

Answer

Yes, the saved locks, which were inherited by the update task, are reloaded to the lock table during startup (see first question).

Question

How fast are lock operations?

Answer

In work processes on the enqueue server, a few 100 microseconds. In work processes of external application servers you have to include network communications and process changes. Depending on CPU and network load this amounts to a few milliseconds.

Question

What should I do first if a problem arises?

Answer

Use the diagnosis functions:

sm12 Extras ® Diagnosis and then

sm12 Extras ® Diagnosis in update

If a problem is reported, back up the trace files dev_w, dev_disp, dev_eq and check the Syslog.

Question

The following message is displayed in the diagnosis details in SM12:

Lock management operation mode

Internal lock management in same process

What does this message mean and what are the other options?

Answer

"Internal lock management in same work process" in the diagnosis function means that you are logged onto the enqueue server and your work process can access the lock table straight away. You do not have to delegate enqueue requests to an enqueue process on a remote enqueue server. If you are logged onto an application server that is not an enqueue server, the diagnosis function will provide you with the name of the enqueue server.

Each SAP System has exactly one application server that functions as an enqueue server. This enqueue server maintains the lock table, which is located in a shared memory segment. All of the work processes on the enqueue server can access the lock table. All work processes on other application servers delegate their enqueue requests to a special enqueue work process on the enqueue server.

This procedure is configured automatically. The parameter line "rdisp/enqname = shows that only the first enqueue process is being used, the bottleneck is due to something else.

Question

Why is an enqueue work process required in a central system? Don't all work processes have the same access to the shared memory and thus to the lock table?

Answer

Although the enqueue process is not used in a central system, it does not do any harm. Since almost all customers install an application server sooner or later, problems will inevitably arise if the enqueue process is missing. For this reason, the enqueue diagnosis function will output an error if an enqueue process has not been configured.

Question

Are the locks in the lock table also set at the database level? If not, database functions could be used to process objects locked in the SAP system.

Answer

Locks are not set on the database. The lock table is stored in the main memory of the enqueue server.

Question

Is a lock table built if an enqueue work process is not started on the enqueue server in the instance profile?

Answer

Yes, because the work processes on the enqueue server use the lock table directly, and not via the enqueue process. The latter is only responsible for lock requests from external application servers.

Question

How can I find out who is currently holding the ungranted lock? In other words, how can check the program after an ENQUEUE to determine which use is currently holding the lock so that I can let him or her know?

Answer

When the ENQUEUE_... function module is returned, the name of the lock owner is listed in SY-MSGV1.

Question

Can I use special characters in my lock argument (especially the ‘at’ sign (@))?

Answer

The ‘at’ symbol is used as a wildcard in SAP locks (enqueues). In other words, it can stand for any other character during collision checks. For example, the parameter value 12345@ locks the quantities 123450 to 123459, 12345a to 12345z, and 12345A to 12345Z, and all other values with any special character in the 6th character position.

This is described in detail in the section Lock Collisions.

In order to prevent the wildcard mechanism from being activated in SAP locks when it is not required, you need to ensure when enqueue function modules are called that key value parameters do not contain any wildcard characters.

If key values that you want to use to lock individual entities do contain wildcard characters, you have to replace the wildcards with different characters before the enqueue is called.

Question

With a single-process system as an enqueue server, we have reached X SD Benchmark users. Can this number be increased by using a multiprocessor system (message server on the same machine as the enqueue server)? Can we assume that scaling is linear (number of CPUs * X SD users)? How many processes are advisable if message servers, dispatchers, one dialog, and two enqueue processes are to run on the system?

Answer

A significant increase in the enqueue server throughput can be expected by using several processors. The CPU load on the enqueue server is distributed relatively evenly between message server, dispatchers, and enqueue work processes, which means that up to 3 processors can be occupied simultaneously. Dispatchers and message server represent the bottleneck with the enqueue.

Linear scaling can be expected for up to 3 processors, even if lock requests are so frequent that message server, dispatchers, and work processes are occupied simultaneously. Due to asynchronous system processes (for example, syncer), using more processors can further enhance throughput.

Question

The Syslog often contains messages such as "Enqueue: total wait time during locking: 2500 seconds". How should I analyze this problem? Or is the entry not critical? (There are no records of terminations or timeouts.)

Answer

The message is output for information purposes only but may indicate parallel processing errors with ABAP programs. The specified wait time is the time that has elapsed since startup due to the use of the WAIT parameter when the enqueue function module was called.

The WAIT parameter enables a lock attempt to be repeated a number of times, for example, so that the update task does not have to be cancelled when a lock is set temporarily by other programs. The work process remains busy between the lock attempts.

Reward Points if helpful .

dinesh

[prabhu_04]

For table lock : ENQUEUE_E_TABLE.
Unlock the table : DEQUEUE_E_TABLE.

CALL FUNCTION 'ENQUEUE_E_TABLE'
 EXPORTING
   MODE_RSTABLE         = 'E' "Am using Write Lock 
   TABNAME              = 'ZLOCK_OBJ'  ""Table name.



row level lock -> ENQUEUE_E(tablename). "" like ENQUEUE_EZLOCK_TABLE
Unlock row -> DEQUEUE_E(tablename).