topic Re: necessity of using lock objects in programming in Application Development and Automation Discussions

necessity of using lock objects in programming

jumabek2707 — Mon, 11 Sep 2023 13:01:23 GMT

How nessesary is using a lock objects in programming with updating/inserting/appending data to transparent tables? And what would happen if not to use it in such cases?

And where using it is nessesary?

Thank you in advance!

Re: necessity of using lock objects in programming

Dominik_Tylczynski — Mon, 11 Sep 2023 13:19:42 GMT

Hello jumabek2707

Lock objects are a must in concurrent programming!

Typically a business object is implemented with several transparent tables e.g. sales order - tables VBAK, VBAP, etc. If you are going to create/update a business object, you need to lock entries in all the relevant tables to make sure no one is going to update them in parallel. That is what enqueue / lock objects do for you.

Best regards

Dominik Tylczynski

Re: necessity of using lock objects in programming

matt — Mon, 11 Sep 2023 13:23:05 GMT

That's not parallel programming. That's concurrent use of an application.

Otherwise, spot on. 😉

Re: necessity of using lock objects in programming

thkolz — Mon, 11 Sep 2023 13:37:00 GMT

When you read data, it's not necessary.

But when you add/update/delete data and another process could manipulate the table at the same time, then it's recommended to lock the table beforehand.

Re: necessity of using lock objects in programming

Dominik_Tylczynski — Mon, 11 Sep 2023 13:39:57 GMT

matthew.billingham Thank you! - updated "parallel" to "concurrent"

Re: necessity of using lock objects in programming

Sandra_Rossi — Mon, 11 Sep 2023 18:19:55 GMT

You can find many answers in the SAP forum:

need of lock objects site:sap.com

Re: necessity of using lock objects in programming

Patrice — Tue, 12 Sep 2023 16:21:10 GMT

Hi Zhumabek,

It is used all the time, but it really depends on the situation. Here is an example.

Let's say you have a program that displays the content of a table in a grid, and allows to change the content, and save it in the database. Now Bob calls this program and displays the content of the first record. A minute later, Jane calls the same program and also displays the content of the first record. Then Bob changes the value of field A on that record and saves it in the database. In SAP this change will not automatically be shown on Jane's screen. It would require the program to reload the data from the database. Jane, not knowing that Bob made a change in field A on the first record, also changes the same field on the same record, puts in a different value and save. Now Bob has lost its changes and will not be notified of the situation.

To prevent this sort of situation, SAP provides Lock Objects. The creation of a Lock Object generates two distinct Function Modules: the Enqueue Function and the Dequeue Function. The first locks an entry, the second unlocks it. If you try to call the first one when it has already been called by someone else (or even by yourself on another session), the Function will return an error. You can see current lock entries by calling transaction SM12.

Now, two things to know about Lock Objects:

Lock Objects in SAP don't actually "lock" the entries. They simply create a lock entry in a table. It is your responsibility as a programmer to use this information and determine what to do when you detect that something has already been locked. Nothing will prevent you to make a database change if you don't check if a lock entry exist or not.
Lock entries are Key specific. This means that if you call the Enqueue Function without specifying a key (to lock the entire table), and another program calls the same Enqueue Function with a specific key, it will not detect that there is already a lock entry since the lock entry without a key and the lock entry with a key are two different lock entries that don't block each other.

I hope this helps.

Patrice Poirier