Mutual Exclusion for Scheduled Job

[acarrasco]

Hi everyone,

Is there any suitable way to prevent a Scheduled Job from being executed more than once at a time (either using scheduling or 'Execute Now' options)? Doing some research, I've seen some information on the wiki about a semaphore class (GlideMutex):

http://wiki.servicenow.com/index.php?title=Serialize_Using_a_Lock_(Mutex)#gsc.tab=0

which seems to be either deprecated or not recommended for use, as suggested on:

Where is the document for GlideMutex?

Anyone has some insights about lock control in ServiceNow? Is it possible to achieve this funcionality at the moment? Any experience to share about using GlideMutex?

Thanks for your help, guys!

Alber.

[Ankur Bawiskar]

Hi Alberto,

So you want the scheduled job to be executed only once.

In the Run option you can see the drop down of Once and you can give date/time to run.

Is this what you want?

Mark Correct if this solves your issue and also hit Like and Helpful if you find my response worthy based on the impact.

Thanks

Ankur

[acarrasco]

Hi Ankur,

Thanks for your answer, but it is not exactly what I wanted to do. Maybe for a better explanation, you may have a look at my other answer below,

Alber.

[Gurpreet07]

This should be possible by making the schedule job conditional. In Condition GlideRecord 'sys_trigger' and find out a record corresponding to the schedule job. If state of sys_trigger is running then set answer to false, true otherwise.

[acarrasco]

Very promising approach, Gurpreet (thanks!), but sadly it does not cover all my requirements

The thing is, when the Scheduled Job is scheduled to be executed at some time, when that time comes, the 'state' field of 'sys_trigger' gets updated, as you pointed. However, if the Scheduled Job is executed manually (button 'Execute Now') the 'state' field of 'sys_trigger' does not get updated. As a result, if one manual execution is performed, and then one scheduled execution starts, both executions would run simultaneously, which is what I persue to prevent (the 'status' field check by the condition of the scheduled execution would find it set to 'Ready').

I don't know if I explained mysef well. I spoke about lock primitives on my first messages beacuse I think that is the natural point of view to approach this problem from a programming perspective.

Once again, thanks a lot. It has been the best approach I've come across so far.

Cheers,

Alber.