topic Re: Loop for locking issue in Application Development and Automation Discussions

Loop for locking issue

Former Member — Wed, 12 Aug 2009 08:49:41 GMT

HI,

i have to delete entries from Z table and i want to verify 2 things :

1. if the entry is update by another program do i need to use the lock concept ?

2. if the entry updated by user when i want to lock the entry i want to do loop and wait

until the table released by user ,my question is how much time i need to do that .

there is any sap program that do the looping on the locked table until it resaled ?

Regards

Joy

Re: Loop for locking issue

former_member386202 — Wed, 12 Aug 2009 08:51:56 GMT

Hi,

Yes u have to lock the table before update, refer following code

*--Check if monitor table is initial

IF NOT gt_hdrlog[] IS INITIAL.

LOOP AT gt_hdrlog INTO ls_monitor.

*--Lock the DB table ZAPT_AR_MONITOR before updation

CALL FUNCTION 'ENQUEUE_EZAPT_AR_MONITOR'

EXPORTING

mode_zapt_ar_monitor = lc_x "Check

mandt = sy-mandt "Cient

doc_num = ls_monitor-doc_num "IDOC number

x_doc_num = lc_x "Check

EXCEPTIONS

foreign_lock = 1

system_failure = 2

OTHERS = 3.

IF sy-subrc NE 0.

WAIT UP TO 1 SECONDS.

ELSE.

*--If DB table is locked then insert data into custom table

INSERT into zapt_ar_monitor values ls_monitor.

IF sy-subrc NE 0.

*--Update custom table

UPDATE zapt_ar_monitor FROM ls_monitor.

ENDIF.

*--Unlock the table after updation

CALL FUNCTION 'DEQUEUE_EZAPT_AR_MONITOR'

EXPORTING

mode_zapt_ar_monitor = lc_x "Check

mandt = sy-mandt "Client

doc_num = ls_monitor-doc_num "IDOC Number

x_doc_num = lc_x. "Check

*--Clear the work areas

CLEAR : ls_monitor.

ENDLOOP.

Regards,

Prashant

Re: Loop for locking issue

Former Member — Wed, 12 Aug 2009 19:30:31 GMT

HI Prashant Patil

Can u explain the logic please ,

1. why u choose to wait one sec .

2. why u Update custom table

3. the looping reason

Thanks ,

Joy

Re: Loop for locking issue

MarcinPciak — Wed, 12 Aug 2009 20:02:30 GMT

Hi Joy,

Other concept would be:

1) in program A export your table with entries to delete to ABAP memory

2) create separate report (B) wherein:

a) import this table back from ABAP memory

b) check if each entry (within loop) is not currently changed by someone else -> for this call locking FM for each entry (key fields must be provided in order to get state of that entry in DB)

c) depending on the result sy-subrc = 0 delete the entry you are currently looped from DB and internal table (you have imported)

d) export all entries to ABAP memory once again, but only those remaining ones (which were locked)

e) if any entries were exported, set JOB using fms JOB_OPEN, JOB_CLOSE for the report which you are currently in

d) in JOB details set it to run only once (if it runs correctly next time it will not create new one, otherwise it will keep creating new jobs trying persistenlty to delete those remaining entires), set it i.e to run in five minutes time

3) submit report B with RETURN option in place where you would normally do deletion (in program A)

This is just an idea but has to be tested and aligned if needed, but would solve with deleting all the entries by recursive calls which are done periodically.

Regards

Marcin

Re: Loop for locking issue

Former Member — Wed, 12 Aug 2009 20:21:42 GMT

HI Marcin,

Thank you,

Do u have a program that following this procedure ?

Regards

Joy

Re: Loop for locking issue

MarcinPciak — Wed, 12 Aug 2009 20:26:31 GMT

Unfortunatelly no, I just made it up for you.

I don't know if this is best practise approach but will likely to work.

Maybe there could be some other (simplier) solution with asynchornous calls which could also solve it, maybe some function module which I am not aware of. But for the moment this was the only thing which came to my mind. You may try it. Don't hesitate to share your doubts if any reached.

Regards

Marcin

Re: Loop for locking issue

Former Member — Wed, 12 Aug 2009 20:39:37 GMT

HI Marcin,

Thank you

i think its good idea Tomorrow i try to implement it and let u know ,

1. i provide class with method which always delete one entry per user ,per specified key

do i need to do loop for that also and export to memory ?

2. i am not using report so what should i change in your flow ?

Best Regards

Joy

Re: Loop for locking issue

MarcinPciak — Wed, 12 Aug 2009 21:08:34 GMT

No problem Joy,

As for the questions:

1) I think you can do two things:

- either create a method which collects all these entries for deletion and then sends it to the unit which would delete them (preferably program as this only can be run via JOB)

- call your method with specified key and if deletion of that entry fails than do recursive call on that method once again


method del_meth.
  delete ....
  if sy-subrc <> 0.
      wait .... "wait can be added, as this unit would execute teens/houndreds of times in one second , so waste of time as entry is probably still locked
      me->del_meth( ...) "call myself once again with same key
  endif.
endmethod.

...so it would over and over again try deleting this certain entry. This solution however results in occupying work process for all the time it executes so it might dump out the program in case the entry is locked for too long (i.e. if someone went for lunch and meantime is editing some table entry;) )

2) you can still stick to OO approach and just call your program B from a method, once you collected all entries within second method. Please note that sending each entry for deletion in program B would result in separate JOB opening for each locked one, so this could have dramatic influence on system performance. That's why I would recommned to get these data together to some table and then exchange this table with program B. At the end you may RETURN from the program and keep executing your program A. At the same time program B will schedule itself to run again and again if update fails in subsequent runs.

Of course these are just my suggestions, you shall do as you feel the best is. Note also that if deleting these entries are crucial for further program A execution, this approach might not be what you are looking for, so we would have to think of alternative solution.

Regards

Marcin