Deadlock with Enqueue Module

[Former Member]

Hello All

We are implemententing a standard-cum-customized solution for Task and Resource Management in selecting tasks. The process here is selecting the best tasks available for the user and locking these tasks using ENQUEUE_ETLTKPLE for task pool table (LTKPL).

The above process of picking the tasks is initiated by a RF device and in our integration testing we realized that if 3/4 people sign in and try to perform the tasks, the system enters in a deadlock in trying to get the lock and dumps. The following the code which enqueues a task:

....Lock Task........................................................

CALL FUNCTION 'ENQUEUE_ETLTKPLE'

EXPORTING

locat = i_locat

taski = i_taski

collect = trmgcx

_scope = '3'

EXCEPTIONS

foreign_lock = 1

system_failure = 2

OTHERS = 3.

IF sy-subrc EQ 0.

CALL FUNCTION 'FLUSH_ENQUEUE'

EXCEPTIONS

foreign_lock = 1

system_failure = 2

OTHERS = 3.

e_subrc = sy-subrc.

IF sy-subrc <> 0.

• Empty container

CALL FUNCTION 'RESET_ENQUEUE'.

ENDIF.

ENDIF.

Any help to resolve the above would be great appreciated.

Thanks

Sunil Achyut

[Former Member]

Normally locks are in place only for the time that it takes to do the updates:

Lock(s)

Update(s)

Unlock(s)

Any longer and you will run into the problem you are having.

Rob

[Former Member]

Rob

Is there any other way for this, I am trying to prevent a single task being given to multiple users. Since we are kind of customizing (in BADI & Zing out a FM) and using standard, am not sure if there is a way where I can prevent multiple RFs getting the same tasks other than locking them through Enqueue FM.

Any hints would be great helpful.

Thanks

Sunil Achyut

[RichHeilman]

How long is the task locked for? Can you wait till it is released? There is a parameter on the ENQUEUE function module _WAIT, set it to "X" to wait. It will wait for a time specified system wide for the lock to be released, this may prevent the dumping. If the lock is held too long, then this will probably not work for you.

Regards,

Rich Heilman

[Former Member]

Rich

In my case if a task is locked, it has to be skipped. In other words, the program shouldnt wait for it. The process is if a resource is given certain tasks, he normally completes them and if two resource sign on and request for tasks at quick succession thats when the deadlock is occuring.

Is there a way that if a task is locked, its skipped rather than waiting for it to be released. Is there another way to lock an task without causing the deadlock, if there please suggest.

Thanks

Sunil Achyut

[Former Member]

So instead of dumping, have the program complete with a message "Tasks locked - try again later".

Rob

[RichHeilman]

I agree with Rob, you should be able to check sy-subrc = 1, then give a message.

Also, I'm not sure what this is all about. Do you need it?

IF sy-subrc EQ 0.
CALL FUNCTION 'FLUSH_ENQUEUE'
EXCEPTIONS
foreign_lock = 1
system_failure = 2
OTHERS = 3.

e_subrc = sy-subrc.

IF sy-subrc <> 0.
* Empty container
CALL FUNCTION 'RESET_ENQUEUE'.
ENDIF.
ENDIF.

Regards,

Rich Heilman

Message was edited by: Rich Heilman

[Former Member]

Rob Rich

Thanks for your input. Rob even I would have expected to return sy-subrc <> 0, but in my case once it goes in the enqueue FM, the control never comes back to my program and the dump happens because of max time for a script exeuction.

Rich it was my understanding that 'FLUSH_ENQUEUE' send the local locks to the server and if the server already has a lock for the current record the 'RESET_ENQUEUE' deletes all the locks of the local container. I wouldnt have known this if I hadnt debugged the SAP standard code, and I realized this was the right way and had to put the same in my locking logic.

After some research I found out that, before trying to lock I have to first check the locks in SM12 by calling the FM 'ENQUEUE_READ' and if someone else holds the lock skip the locking logic and process another task. Am I right in my assumption, and would appreciate any suggestion you might have.

Thanks

Sunil Achyut

[RichHeilman]

Ok, interesting, I never really had a requirement quite like yours, I have always used the WAIT parameter so that it would wait for the release of the lock, in my case it was ok to wait for a second or two. Give it a try with the ENQUEUEREAD. That makes sense to me.

Even on a Saturday, I learned something new. Thanks for that.

Regards,

Rich Heilman