Application Development Discussions
Join the discussions or start your own on all things application development, including tools and APIs, programming models, and keeping your skills sharp.
cancel
Showing results for 
Search instead for 
Did you mean: 

Recommended retry for ENQUEUE process

suwandi_cahyadi
Contributor
0 Kudos

Hi Experts,

I'm planning to put a retry when failing to get a lock object in my ABAP program.

I know that we can use the _wait parameter in FM. But I prefer to use a custom wait-time and max-retry, so I plan to call the ENQUEUE FM inside a DO.x TIMES. ENDDO.

But I'm afraid that calling ENQUEUE too many times could eat too much resource or impact in bad performance. (According to the basis team, the enque/table_size is configured as recommended by SAP, an so far it is still enough)

Is a 2 seconds interval, up to 30 times (results in max 1 minute wait before giving up getting the lock) is a worrying number?

Is it true that calling ENQUEUE too many times could result in SAP lock table overflow even if the lock is not acquired?

Thank you,

Suwandi C.

1 ACCEPTED SOLUTION

naimesh_patel
Active Contributor
0 Kudos

The Lock table overflow can only occur if the locks are not getting released. Like if you have program where you are updating 1M records. If your program is like this:

  • Lock all 1M records
  • Process the records and update the table
  • Unlock all 1M records

In this instance, the lock table overflow can occur if the lock table can't hold 1M records.

When you implement the DO.. ENQUEUE.. ENDDO, the lock table overflow can't occur, if you implement it properly. It should be implemented like:

DO n times

  call ENQUEUE FM

  if sy-subrc eq 0.

    locked = 'x'

    EXIT

  else.

    WAIT UP TO 1 SECOND

  endif.

Enddo.

if locked = 'x'

  call DEQUEUE FM

  call BAPI to update

else

  error handling, lock not applied

endif.

If you should put the loop time and wait second, in configurable table say TVARVC so it can be controlled easily.

In this instance, you would always have only 1 entry in your lock table, When you try to lock it again using the ENQUEUE FM and if it fails, there is an existing lock entry. if it succeed, you would have a new lock entry.

Regards,
Naimesh Patel

2 REPLIES 2

former_member220028
Active Contributor
0 Kudos

Hi,

i think 30 table reads a min is no performance problem...

during migration we set alot enqueues. and we did without wait statement still the rest of the system worked fine.

regards

Stefan Seeburger

naimesh_patel
Active Contributor
0 Kudos

The Lock table overflow can only occur if the locks are not getting released. Like if you have program where you are updating 1M records. If your program is like this:

  • Lock all 1M records
  • Process the records and update the table
  • Unlock all 1M records

In this instance, the lock table overflow can occur if the lock table can't hold 1M records.

When you implement the DO.. ENQUEUE.. ENDDO, the lock table overflow can't occur, if you implement it properly. It should be implemented like:

DO n times

  call ENQUEUE FM

  if sy-subrc eq 0.

    locked = 'x'

    EXIT

  else.

    WAIT UP TO 1 SECOND

  endif.

Enddo.

if locked = 'x'

  call DEQUEUE FM

  call BAPI to update

else

  error handling, lock not applied

endif.

If you should put the loop time and wait second, in configurable table say TVARVC so it can be controlled easily.

In this instance, you would always have only 1 entry in your lock table, When you try to lock it again using the ENQUEUE FM and if it fails, there is an existing lock entry. if it succeed, you would have a new lock entry.

Regards,
Naimesh Patel