ABAP log

May 2, 2007

SAP Locks Mystery.

Filed under: ABAP, SAP — abaplog @ 8:19 pm

I was kicked once by some problem that lies on how SAP behaves when you create locks with Enqueue functions. The locks were at the first glance mysteriously released (or seemed to allow concurrent locking, though it was requested as exclusive).

Using locks in SAP is easy, and the functionality is well described in SAP Help and in the ABAP Knowledge Corner article from Richard Harper.

So, because of the apparent simplicity, all that seemed very suspicious. After playing with debugger and SM12, I have found that the problem is with the parameter _SCOPE of the locking functions. By default, as generated by SAP template generator in SE38, it’s set to 2, which means it’s released in the calling program and transferred to the update task, if the program does such calls. As soon as the update is over, the lock is deleted. If you have COMMIT AND WAIT after the call function, it can be very amusing to have the lock gone. The solution was to set it to 1, so that the lock ownership is not transferred (the functions I call do not depend on the objects I lock).

To extend the standard documentation and the article from Rich, I would add the following regarding the parameters for ENQUEUE functions:

The parameter _SCOPE defines where the lock affects the data in case the locking program does update task calls (which may be implicitly done by calling normal function modules, BAPIs or transactions).

With ‘1’, the lock is released only when the ***caller*** program finishes or releases the lock explicitly. If the lock is done in exclusive mode, the update task cannot lock the same object (and normally cannot update it).

With ‘2’, the lock is “moved” to the update task. The update task may release it explicitly, otherwise the lock will be released when update task is finished. After calling the update task, the caller has nothing to do with the lock. Example pseudocode:

Example 1:

call ENQUEUE with _SCOPE=2
call function FUNC. “synchronous call – no update task
call DEQUEUE “clean up – lock is released

Example 2:

call ENQUEUE with _SCOPE=2
call function FUNC in update task. “async call
commit work and wait. “we want to wait for update till it’s done
call DEQUEUE “oops! we have nothing to release here! the lock is gone as soon as FUNC exits!
“Other processes can lock the same object, even as we may expect them to be denied

With ‘3’, the lock created by caller is “copied”. After that, both caller and update task own their locks. The locks will be released either explicitly with dequeue, or when respective process is done. If the original lock was exclusive, as long as one of those two locks exist, no other processes can obtain a new exclusive lock.


Leave a Comment »

No comments yet.

RSS feed for comments on this post. TrackBack URI

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Blog at WordPress.com.

%d bloggers like this: