Professional Documents
Culture Documents
SAP
http://www.sapyard.com/logical-lock-vs-physical-lock-in-sap/#comment-8490
This morning I had a chat with an ABAPer who has few months of experience
after training. While discussing he said if a table is ENQUEUED (locked
for change) in one session, no one else can modify/update that table. I tried
to explain that the statement is not completely true. This post is an
extension of that conversation.
There are quite a few good articles and blogs on Locking Concept. We are
not going to sing the same song here. Today we would focus our discussion
on just two words, Logicaland Physical.
If you ask anyone, what is the difference between Database Lock and SAP
Lock, the knee-jerk answer is Database Lock is a Physical Lock and SAP
Lock in a Logical Lock. For seasoned and experienced consultants, it is not
difficult to assimilate and understand these two words. But freshers and
newbies might have some questions which they are reluctant to ask their
seniors.
Can two ABAPers open the same program in SE38 in change mode in
the same client and system? Or can two functional consultants open the
same sales order in VA02 (change mode)?
A picture is worth a thousand words. Let me demonstrate it in some images.
The SAP Lock would try to throw the error message that a lock is already set
for the program, but you can always bypass the error message and force the
system to pretend that everything is normal and do not spit any venom.
You just need to hit ‘/h’ and hit enter in the same program in the second
screen in SE38 in change mode a second time. Then put a dynamic
breakpoint at statement ‘MESSAGE’.
When the system would identify that a Lock is already there for the program
and it would try to throw the error message, just use your debugging skill to
get past the error (put the cursor on the next executable line and jump to
that line without allowing the error message line to be executed).
Menu: Debugger -> Goto statement (Shift + F12) (This helps to jump
statements)
Boom.. You are now editing the same program in two screens in the same
client in the same system.
Whether you would be able to change and activate in both the editable
screen, you need to try it yourself to find it out. Let us know whether you
were able to activate the changes in both screen. We would be happy to
reveal, what we found.
Logical means the developer has to use his discretion and handle the locks
logically. If someone has already locked something, if you want,
you CAN make change simultaneously. But whether you should be changing
something when someone else is trying to change at the same time? That is
the logical question. SAP Locks are not physical.
Let us look another example. This would make the picture clearer.
For our freshers: Database locks are set by data changing SQL
statements such as INSERT, UPDATE, MODIFY etc. These are physical locks
and are held until the SQL statement COMMIT is reached. Once the
COMMIT statement is executed the DB lock is released.
Execute the program in one session and the execution stops at COMMIT
statement. Since the database executed the UPDATE statement, a database
lock is set by the database. We can check the database lock using T-
code DBACOCKPIT (follow the path highlighted in the below image). If you
do not have access to this t-code, go to your Basis team and ask them to
show you this lock.
Now let us run the same program in another session and set our breakpoint
at the UPDATE statement.
Remember, the first debugger in the other session is still there at COMMIT
statement i.e. the Physical database logic is still active as COMMIT statement
has not been executed.
You would find that even if you hit F5, F6 or F8, you cannot get past the
UPDATE statement for the second run. This is Physical. No matter how hard
you try, you cannot UPDATE the same table if the first lock is not released.
I walked to the washroom, went to the cafeteria and fetched a glass of water
and returned to my desk (6 to 8 minutes). The second session was still trying
to get past the UPDATE statement. I came back and executed the COMMIT
statement in the first debugger and boom, the UPDATE statement is
executed on the second screen and waiting on COMMIT statement.
For your reading pleasure, you can refer to this external link for the R/3
Lock Concept.
Scott G. said:
It’s not an SAP thing. The locks in SAP are logical, in that you hold your locks
by building function modules for Enqueue and Dequeue (SE11) and see the
locks in an online report (SM12).
The actual lock is up to how you configure your database that the data
dictionary sits over. You could set your database to row locking, field locking,
or even table locking.
Again – that’s a code thing. If I built a table called ZSCOTT and write an
ABAP program to modify fields in a row (Update Set Where) but in my code,
I do not enqueue ZSCOTT, then you and I could both be changing fields in
the same row and whoever hits SAVE first wins. I know that sounds hokey,
but it is not.
BJ Torres said:
SAP lock is an application lock. You can alter the behavior in the application
layer (ie. skipping the subrc check via debug). The DML lock is a DB locking
mechanism. Due to the strict ACID principle, you cannot cheat your way into
clearing the lock like what you did in SAP (which relies on the DB to maintain
ACID). (Please check the comment section below for full feedback)
If you liked this post, please hit the share buttons and like us on facebook.
Thank you very much for your time!!