Why doesn't call transaction <trans name> update 'S' wait for commit

[Former Member]

Hi All,

I'm using call transaction <trans name> update 'S' .

I read that update 'S' means the program will continue only after all V1 update tasks have finished.

However on the next line of code I still encounter locks because of the above process.

Any Idea why that is ?

Thanks

Ziv.

[arseni_gallardo]

Ziv,

That's because of the V2 updates. This happens a lot in the SD module. If you want to make sure that all the changes have been commited to the database right after the call transaction you must use the local update ('L') instead of the synchronous update ('S').

[Sandra_Rossi]

Hi,

I know that people have this issue "very" often, but I could never find any evidence of what happened exactly (often, it's solved by using S or L update mode). Do you have any reference documentation that explains what you say?

AFAIK, locks are removed at the end of the V1 task, they are not passed to the V2 (http://help.sap.com/saphelp_nw70/helpdata/en/41/7af4d1a79e11d1950f0000e82de14a/frameset.htm : "The entries in the lock table are usually deleted once the V1 step has been processed. There is no locking for the V2 step")

Moreover, about the locking process, I think a local update does the same as a synchronous update ([SAP library - Local updates|http://help.sap.com/saphelp_nw70/helpdata/en/41/7af4d7a79e11d1950f0000e82de14a/frameset.htm]). Again, I'm ready to hear anything, I think I miss something.

Sandra

[Former Member]

Thanks Arseni,

I've tried your suggestion and also used

SET UPDATE TASK LOCAL before calling

call transaction <trans_name> update 'L'...

But the results were the same, I still encounted a lock.

Ziv

[Former Member]

Thanks Sandra,

I've open an OSS ticket. Their replay was that update 'S' or 'L' is not enought and some wait logic will have to by implemented.

Your st05 hint was very helpful by the way , I never notice the enqueue trace option.

Ziv.

[SuhaSaha]

Hi Ziv,

I've open an OSS ticket. Their replay was that update 'S' or 'L' is not enought and some wait logic will have to by implemented.

Synchronous update in CALL TRANSACTION(analogous to COMMIT WORK AND WAIT) will cause the program to wait for the V1 updates to be completed. And as per the link provided by Sandra, locks are released when V1 updates are completed & not carried forward to V2 updates! The reply is inconsistent with what SAP documentation states

I have seen this particular issue being raised in the forum many a times. Is it an SAP kernel issue which causes this anomalous behaviour?

BR,

Suhas

[Former Member]

Thank you all,

Eventually I used Enqueue_read function to look for locked records and wait for their release :

(I'd love to see other suggestions )

 
DATA : lv_garg TYPE string, 
         lv_iter TYPE i, 
         lt_enq   TYPE STANDARD TABLE OF seqg3. 

  CONCATENATE sy-mandt im_garg INTO lv_garg. 

  DO. 

    CALL FUNCTION 'ENQUEUE_READ' 
       EXPORTING 
         gclient                     = sy-mandt 
*         GNAME                       = ' ' 
*         GARG                        = ' ' 
         guname                      = sy-uname 
*         LOCAL                       = ' ' 
*         FAST                        = ' ' 
*       IMPORTING 
*         NUMBER                      = 
*         SUBRC                       = 
        TABLES 
          enq                         = lt_enq 
       EXCEPTIONS 
         communication_failure       = 1 
         system_failure              = 2 
         OTHERS                      = 3 
                . 
    IF sy-subrc = 0. 
      READ TABLE lt_enq WITH KEY gname = im_gname garg  = lv_garg TRANSPORTING NO FIELDS. 
      IF sy-subrc = 0. 
        lv_iter = lv_iter + 1. 
        WAIT UP TO lv_iter SECONDS. 
      ELSE. 
        EXIT. 
      ENDIF. 
    ENDIF. 

  ENDDO. 

Edited by: Ziv Katz on Sep 12, 2011 12:34 PM

[Sandra_Rossi]

Hi,

That's right, if locks are passed to the update task, they are removed at the end, otherwise they are removed at the end of the transaction.

So, there are 2 possibilities why you still get a lock:

1) Kernel error -> check SAP notes, or contact SAP support.

2) the called transaction starts an asynchronous task/job that adds this lock -> check the enqueue trace (ST05) to make sure which process adds the lock.

Sandra

[Former Member]

A comment: BDC/Call Transaction should be done in S-synchronous update mode, so that you can verify the results by examining return code and message tables. Remember that in SD many, many tables are updated by a document insert or update. You will see the same problem in other modules, and users sometimes encounter when trying to immediately process a document they just saved or updated. This is not an "issue" so much as a need to understand what is happening in the DBMS and in SAP. You will see this frequently in processing multiple steps for related documents.

Easy fix:

check for zero return code....

Put in a wait....."wait up to nnnn seconds." Experiment with how much time you need....too much is better than too little, obviously.

then proceed with your code.