Skip to Content

Every ABAP programmer knows the commands COMMIT WORK and ROLLBACK WORK, so everyone should be able to answer the following question:

“Do behave COMMIT WORK and ROLLBACK WORK different if you look at lock objects?”

I guess that most ABAP programmers will answer something like “There is no difference in the behaviour. After each one of the commands SAP locks are gone.” But it is true?

Let’s take a look at the lock object EBU_PARTNR that performs a write lock on the table BUT000 and locks a certain business partner. So please run following code an look at transaction SM12 during the waiting time:

CALL FUNCTION 'ENQUEUE_EBU_PARTNR'
  EXPORTING
*   MODE_BUT000          = 'E'
*   CLIENT               = SY-MANDT
    partner              = '1234'
*   X_PARTNER            = ' '
*   _SCOPE               = '2'
*   _WAIT                = ' '
*   _COLLECT             = ' '
EXCEPTIONS
   foreign_lock         = 1
   system_failure       = 2
   OTHERS               = 3.

ASSERT sy-subrc = 0.
ROLLBACK WORK.
WAIT UP TO 20 SECONDS.

If you run this code it behaves as expected: After ROLLBACK WORK the lock is deleted in SM12. But now run following code: 

CALL FUNCTION 'ENQUEUE_EBU_PARTNR'
  EXPORTING
*   MODE_BUT000          = 'E'
*   CLIENT               = SY-MANDT
    partner              = '1234'
*   X_PARTNER            = ' '
*   _SCOPE               = '2'
*   _WAIT                = ' '
*   _COLLECT             = ' '
EXCEPTIONS
   foreign_lock         = 1
   system_failure       = 2
   OTHERS               = 3.

ASSERT sy-subrc = 0.
COMMIT WORK.
WAIT UP TO 20 SECONDS.

I guess you will be surprised: The lock object still exists after COMMIT WORK and vanishes after 20 seconds of waiting time. Do you know why? Here is a hint for solution: 

CALL FUNCTION 'ENQUEUE_EBU_PARTNR'
  EXPORTING
*   MODE_BUT000          = 'E'
*   CLIENT               = SY-MANDT
    partner              = '1234'
*   X_PARTNER            = ' '
*   _SCOPE               = '2'
*   _WAIT                = ' '
*   _COLLECT             = ' '
EXCEPTIONS
   foreign_lock         = 1
   system_failure       = 2
   OTHERS               = 3.

ASSERT sy-subrc = 0.

DATA dummy TYPE sbook.
CALL FUNCTION 'SAPBC_FLBOOKING_UPDATE' IN UPDATE TASK
  EXPORTING
    lv_sbook       = dummy.
COMMIT WORK.
WAIT UP TO 20 SECONDS.

Now the lock object is deleted after COMMIT WORK – but why? The update module  SASAPBC_FLBOOKING_UPDATE inserts an empty row in the SBOOK table of the SAP flight data model. But why does this change the behaviour of COMMIT WORK? The reason is explained in SAP library if you search for the _scope parameter: “The default value 2 of the _scope paramter of the function module ENQUEUE_EBU_PARTNR means that the lock belongs to the update owner (owner_2) 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.”

The Solution

The last sentence explains the behaviour. If we perform database updates directly as above without using update modules (or services like object services that use them within the framework) than it is likely that after a COMMIT WORK locks still exists.

What can we learn? 

This can lead to an unexpected behaviour of our programs. Just think a report that locks a certain row of a table, than performs an update and after 10.000 of those operations does a COMMIT WORK to save a bulk of changes to the database and then works on the next 10.000 items and so. If we don’t use update modules for database changes the lock objects still exists and will vanish not until end of the report – and this could be much too late.

To overcome this problem we should use update modules or should call function modules that do a dequeue and remove the locks.

To report this post you need to login first.

8 Comments

You must be Logged on to comment or reply to a post.

    1. Tobias Trapp Post author
      This is what I suggested in the last sentence. It’s appropriate for simple reports but for bigger applications I think this is a desaster: In a complex business process I will update a lot of business objects – perhaps a customer will even enhance my application. Usually a COMMIT WORK is like “fire and forget”: I don’t want to have to dequeue a possible complex set of objects afterwards by myself.
      (0) 
        1. Tobias Trapp Post author
          Of course this could help but I don’t recommend it as a general solution: What happens to the locks that “survive” COMMIT WORK and are released after execution of V1-tasks? I think DEQUEUE_ALL removes those locks too early.

          And this is the problem: In my opinion COMMIT WORK shouldn’t make any assuptions on the specific locking-parameters and whether there are updates functions modules or not. This gets even more important if you want to create software that can be enhanced.

          Cheers,
          Tobias

          (0) 
  1. Sameer A
    During the migration process problems have been reported for this blog. The blog content may look corrupt due to not supported HTML code on this platform. Please adjust the blog content manually before moving it to an official community.
    (0) 
    1. Tobias Trapp Post author
      I think It would be better if I would have added some comments. In my example I wanted to show, that in some cases the lock remains:

      COMMIT WORK. “Here the lock remains
      WAIT UP TO 20 SECONDS. “Watch out in se12. The lock still exists!
      * After 20 seconds the report is over and with its end the lock vanishes.

      The putpose of teh WAIT command is to show that in some cases COMMIT WORK doesn’t remove the locks.

      (0) 
  2. Sameer A
    Excuse me for my previous post, i posted it by mistake.
    Again please excuse me if my understanding of ABAP is wrong but it seems to me that the code below should retain the lock for 20 seconds, not the one above.
    Maybe you just switched two codes by mistake.
    (0) 
  3. Clemens Li
    Yeah, this is an error even SAP developers dir not think of:

    I.E. function module CALL FUNCTION ‘BAPI_MATERIAL_MAINTAINDATA_RT’ a bunch of enqueue locks are set, then the update is prepared and in case of changes the respective update modules are called. But if no changes are determined, the update modulesare not called and the locks remain set even after commit work.

    There is a SAP note that adds a call to FM ‘MATERiAL_UPDATE_DUMMY’ (or comparable name) that is called IN UPDATE TASK an will trigger the release of all locks set with SCOPE = 2 wnen triggered by COMMIT WORK.

    This means: You have to call at least one FM IN UPDATE TASK. Otherwise your locks are not released.

    Regards,

    Clemens

    (0) 

Leave a Reply