locking issue with BAPI_GOODSMVT_CREATE

[Former Member]

Hello,

Has anybody ran across a problem of lock objects (related to materials) not getting released when BAPI_GOODSMVT_CREATE fails?

Here is the sequence of events:

1. I run my function (which calls BAPI_GOODSMVT_CREATE) in SE37 and force an error (i.e. return table contains entries). I do NOT leave SE37.

2. In another session I run the same test again (but with correct data). I get error M3 897 (The plant data of the material 3319 is locked by user USCLXH90).

By looking in SM12 after step 1 is finished, I have noticed that 2 lock entries do not get released. These lock entries subsequently cause the error in step 2.

Lock Object: ENQARRAY

Tables: MARC, MBEW

Arguments: material and plant used in my test

IMPORTANT NOTES:

A. These lock objects do finally get released once I completely exit SE37.

B. These lock objects get released immediately and automatically if step 1 is successful (in other words, it's only when there is an error do the lock objects remain!)

C. I do call BAPI_TRANSACTION_COMMIT. I have also tried using SET UPDATE TASK LOCAL. Neither makes any difference (I think these are irrelevant b/c there are no db updates anyway in step 1 b/c of the error I force).

D. We have seen this specific problem occur when calling the function via RFC from our web front end.

I couldn't find any OSS note that describes this problem. Anybody know how to guarantee that all lock objects get released in the case where BAPI_GOODSMVT_CREATE fails?

p.s. I am a doing a 541 movement type (although I don't think this problem is specific to movement types).

Thanks for any suggestions or insights anybody might have.

Regards,

Lee

[RichHeilman]

I've used this BAPI in many of my programs, and always after the call, I code.....

    commit work and wait.
    call function 'DEQUEUE_ALL'.

The DEQUEUE_ALL show release any/all locks.

Regards,

Rich Heilman

[Former Member]

Thanks Rich... this make work for me, but one question -

Do you know if this function releases all lock objects for the user system wide or only for the current session? My concern is that if it is system wide, then I could be releasing lock objects for other sessions unintentionally. For example, if there are multiple RFC calls in parallel for the same function and same user then I could be destroying lock entries that I shouldn't be! I am hoping that it removes lock entries only for the current session...

any ideas?

Regards,

Lee

> I've used this BAPI in many of my programs, and

> always after the call, I code.....

>

>

> 
>     commit work and wait.
>     call function 'DEQUEUE_ALL'.
> 
> 

>

> The DEQUEUE_ALL show release any/all locks.

>

>

> Regards,

> Rich Heilman

[RichHeilman]

I gotta say that it will release locks for that "session" only, otherwise what's the point in applying locks in the first place, right?

Regards,

Rich Heilman

[Former Member]

Sorry, "session" is probably not the correct word I should have used.... rather, is this function <i>transaction</i> specific? (because I don't want the all locks for the user in the system released - only those pertaining to the current transaction). Logically, I would assume it's only for the current transaction, but I am just trying to make sure I'm not using some "all encompassing" function that just goes and removes all locks in the system for that user.

....anyway, OSS note 3013 seems to answer my question

Thanks for your help!

Cheers,

Lee

> I gotta say that it will release locks for that

> "session" only, otherwise what's the point in

> applying locks in the first place, right?

>

> Regards,

> Rich Heilman

[Former Member]

Hi Lee,

Did you set the parameter 'WAIT' to 'X'? This will ensure that all the updates are completed and the locks are released, before the next call of the BAPI.

Srinivas

[Former Member]

Hi Srivinas,

Yes ... I had noticed that parameter and made sure that I set it. Thanks.

Lee