Any suggestions for CHEAP improvements to dequeue performance?

[Former Member]

We have a case where we have to call the SO change BAPI twice in rapid succession on the same SO. It would be nice if we could avoid this, but we can't, so let's assume that redesigning the code is not an answer to the problem.

In our dev instance, dequeues are very quick, and as a result, we almost never get "self-contention" on the second BAPI call.

That is, the second BAPI call almost never returns an error saying that the SO is in use by the same user.

But in our first-level QA instance, we were almost always getting this kind of "self-contention" error until we actually put the second BAPI call in a DO loop that executes up to 20 times with a 2 second wait inbetween each iteration. (Note that before taking this extreme measure, we tried calling the "VBAKKE" dequeue function twice (explicit and wildcard) with a 2 second wait, but this didn't help.)

What is causing the difference between dequeue performance in our dev and QA instances, and is there anything CHEAP that can be done to improve performance in our QA instance?

Inquiring minds want to know, so thanks for whatever time you can afford to spend thinking about this matter.

djh

[krishnendu_laha]

is there any explicit commit work between those BAPI call, or requirement is to put those in a single database LUW?

For unlocking the entry, I would suggest DEQUEUE_ALL...

Thanks

[former_member181923]

Hi Krish L -

Thanks for taking the time to respond.

Before we went to the "VBAKKE" dequeue in explicit and wildcard mode, we tried a simple dequeue all that didn't work.

Also, before we put the second call in the DO loop with the wait two seconds, we changed the explicit commit between the two BAPI calls to a commit and wait, and also put a hard wait up to 2 seconds AFTER this commit and wait.

So you can see that our enqueue server must be really suffering, because the only thing that's worked so far is the do loop around the second bapi call, with the 2 sec wait inbetween each iteration.

That's why I'm asking for help from the Basis side, because it's clearly a problem of overload on the enqueue server contention for the lock table at the Oracle level.

Do you (or anyone else) know if the lock table can be parallelized at the Oracle level?

Best

djh