persistent locks??

[Clemenss]

Hi experts,

we have the following phenomenon:

The use of FUNCTION 'BAPI_MATERIAL_MAINTAINDATA_RT' sets a lot of lock entries.

Following the function call we call FUNCTION 'BAPI_TRANSACTION_COMMIT'.

This should start the update process and release the locks. But although COMMIT WORK has been processed, no update process starts and all the locks remain. This causes a lock table overflow if we try to mass-update.

Can you explain this behavior?

Regards,

Clemens

[Former Member]

Sometimes when there is a lot of contention for UPDATE processes, you will not see the commit statement releasing the locks immediately. Depending on how many updates processes your basis defined in your system setup, it may be just waiting for the process to be available to make the commits.

Did you try WAIT option?

[Clemenss]

Hi Srinivas Adavi,

yes, but this is not the case: In our test system, we have 2 update processes. They don't do anything.

Now I tried the WAIT option: Confusingly, it executes the statement and does not wait (in debugger). But all the locks still remain.

Is there any customizing setting possibly avoiding the update?

Regards,

Clemens

[Former Member]

Hello Clemens,

Sometime back i did R&D on this FM ,Unfortunatly i was assigned into other project.

I don't remember the OSS Note but I saw something in oss note regarding this FM.

Look at OSS Note by using search term 'BAPI_MATERIAL_MAINTAINDATA_RT'.

I do remember - MARC Table updation is the major issue.

Thanks

Seshu

Thanks

Seshu

[Clemenss]

Bingo!

there are lots of notes about performance issues and other things.

But there is one not yet one month old and it is titled

Note 1071095 - Releasing blocks with BAPI_MATERIAL_MAINTAINDATA_RT

After application of the note, it works as expected.

Regards,

Clemens