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: 

Cannot cumulate lock within update task

Former Member
0 Kudos

Hi,

I am writing a BAPI to update several materials asynchronously.

1. The BAPI will lock those materials for update by ENQUEUE_EMMARAE with scope 2

2. Calls another function module IN UPDATE TASK, which calls BAPI_MATERIAL_SAVEDATA several times to update those materials.

However, the BAPI_MATERIAL_SAVEDATA fails to accumulate the lock on EMMARAE and rejects the changes.

The BAPI is to return without waiting for the material changes, but block other change attempts in the mean time.

As a work around, I tried to release the lock in the FM before locking again, but it could not be done by DEQUEUE_ALL nor DEQUEUE_EMMARAE.

Please help.

Many thanks,

MF

10 REPLIES 10

Former Member
0 Kudos

Hi

The lock should automatically be released after commit work, so you couldn't call several times the BAPI BAPI_MATERIAL_SAVEDATA without to call a commit for every call.

Max

0 Kudos

Hi Max,

Thanks for the reply.

I tried commit work in the FM. It caused update termination in the update task.

Please help.

MF

0 Kudos

HI M Fung,

1. Write COMMIT

and Dequeue for unlocking

(in the main program, not in the update FM)

(this will not give error)

(commit in update FM is not allowed at run time)

regards,

amit m.

0 Kudos

Hi Amit M,

I understand the commit to trigger the update FM and then dequeue for the FM to acquire the lock again. There is a small risk it may be lost to another process during the short release-and-lock.

Is there no other way to keep the original lock throughout ?

Many thanks,

MF

0 Kudos

Hi again,

1. Lets take this sequence

a) program logic

b) enqueue

update FM

Commit Work and Wait

dequeu

2. In above,

all the 4 statements in B

are executed immediately in sequence.

3. When update FM is called,

it does not execute immediate.

However,since the immediate next

statment is commit work and WAIT,

the update FM will execute (immediate now)

and after completion,

dequeu will be exectued.

4. I think this is the most shortest span

of time, in which u won't have any problem.

regards,

amit m.

0 Kudos

Hi Amit m,

Thanks again for the reply.

Let me see if i am getting this right.

When the update FM executes (in 3), the lock is held by the (1b) enqueue. The FM calls BAPI_MATERIAL_SAVEDATA, which tries to lock again and make the actual changes. Somehow, BAPI_MATERIAL_SAVEDATA fails to cumulate the lock here due to foreign lock. This is within the update FM due to 'commit and wait' before the 'dequeue'.

Please help.

Many many thanks,

MF

0 Kudos

Hi

Your problem is on BAPI_MATERIAL_SAVEDATA, because you have a process in UPDATE TASK where this fm is called severel times, but you do (I understood so) one only commit to run the process in UPDATE TASK.

Your flow should be:

BAPI_MATERIAL_SAVEDATA

commit and wait

BAPI_MATERIAL_SAVEDATA

commit and wait

......

In this way every lock is released after running BAPI.

but you can't do a commit statament in the update process, so I believe it would be better to run the process in update task for only one BAPI

Max

0 Kudos

Hi again,

1. BAPI_MATERIAL_SAVEDATA, which tries to lock again and make the actual changes

If this is so, then i don't think

we need to explcitly Enqueu/Deuque in our code.

The FM will automatically take care of it.

2. FM calls BAPI_MATERIAL_SAVEDATA,

Just after this use commit work and wait !

regards,

amit m.

0 Kudos

Hi,

1. The enqueue before BAPI_MATERIAL_SAVEDATA is to ensure the change should not fail due to another change lock in progress.

2. The whole idea is to commit but not wait, while blocking other attempts to the same materials before the update completion.

I wonder if there is a way to do this with ABAP.

Again, many thanks for the input and discussion.

MF

0 Kudos

Hi Max,

Thank you very much for your reply.

The whole purpose of the BAPI is to commit but not wait, and coordinates the master changes on several materials at the same time. If I can wait, I would have used your suggestion.

I split the lock and update into 2 tasks to ensure commit but no waiting. Update IN UPDATE TASK to inherit the lock. However, although the update task has ties to the lock, it is not exactly its owner, and could not acquire the lock again.

I think I am stuck here.

MF