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: 

ENQUEUE_EMMARAE does not lock material and it does not give a good reason

capilano
Explorer
0 Kudos

I'm looping thru thousands of materials by a block of 100 and using ENQUEUE_EMMARAE to lock the meterials for updates in a batch. Debugging shows ENQUEUE_EMMARAE can not lock material here and there but it does not give a good reason in the message.

I can reduce the block size from 100 to 5 but not sure if it will lock more materials. Or I can set ENQUEUE_EMMARAE parameter from default (1) to max (5) but the question remains: how can I increase the chances of locking a material?

Please assume I'm working on a system that has less users and processes locking materials other than I do. Right now, the lock fail rate is too high for some reason.

Does anybody have any suggestions?

Thanks in advance.

Edited by: baojing shi on Nov 4, 2010 6:24 PM

4 REPLIES 4

Former Member
0 Kudos

Put each material that does not lock into a separate internal table. After the main table has been processed, process the unlocked entries. Do this as many times as need be.

Rob

Former Member
0 Kudos

Debugging shows ENQUEUE_EMMARAE can not lock material here and there but it does not give a good reason in the message.

Not sure what you mean by good reason, but essentially I'd expect to see only one reason why you cannot lock a certain object - it's already locked by somebody (or something) else. Other reasons like problems with the enqueue process (or server) should result in a much broader problem that just failure to lock some materials.

how can I increase the chances of locking a material?

Rob suggested already a very good approach how to handle locking issues. Anyhow, the generic answer to your question would be that there's not that much you can do:

<ul style="list-style:circle">

<li>Run your program at a time when there's less or no users in the system and no other programs lock materials</li>

<li>Ensure that users are not keeping materials open in change mode for long time and that they only use change mode transactions when they really need to change something</li>

<li>Wait longer and retry locking the material a couple of times if you need to process them in a certain sequence; otherwise Rob's suggestion is much better</li>

</ul>

Please assume I'm working on a system that has less users and processes locking materials other than I do. Right now, the lock fail rate is too high for some reason.

Well, as I said above, I'd expect the materials to be locked for some reason. Probably you should monitor in transaction SM12 the locks when you run the program and see what the program does and what other processes hang on to material locks.

capilano
Explorer
0 Kudos

Thanks, Rob and Harald.

I was testing your suggestions in SE37 on ENQUEUE_EMMARAE and I run into another problem. While ENQUEUE_EMMARAE locks a certain material, I can not use DEQUEUE_EMMARAE to unlock it. SM12 shows the lock is on right after ENQUEUE_EMMARAE and DEQUEUE_EMMARAE has no effect at all.

Could you venture an explanation?

Thanks in advance,

Former Member
0 Kudos

I was testing your suggestions in SE37

I'm not sure what you're testing in SE37, but it almost sounds like you're calling the enqueue/dequeue functions there. If that's the case I don't really understand what exactly you're testing. But anyhow, I only see one reasonable explanation for that: If you're really in SE37 and calling the ENQUEUE_EMMARAE and the lock persists even after calling DEQUEUE_EMMARAE, you probably are calling DEQUEUE_EMMARAE in a separate (external) session.

You can easily see once you get back to the screen in SE37 from where you triggered the execution (F8) of the enqueue function module, the lock will automatically disappear without you even having to call the dequeue function.

If that doesn't apply the only other explanation I have is that you missed when calling the enqueue function that there was actually already an existing lock and your enqueue call failed with an exception (which you didn't see).