[Files] Mutex Lock
Q100042: [Files] Mutex Lock
Creates and locks a mutex to use to coordinate processes that might need exclusive access to a resource.
| Parameter | In/Out | Description | Other Info |
|---|---|---|---|
| Mutex name or Pathname | InOut | The name of the mutex, which should be unique for all of the processes that will share/use it. This can be specified as a fully qualified pathname for the file that will serve as the mutex if desired. | |
| Wait for mutex if locked? | In | Choices: StopImmediately, WaitForAWhile, WaitAsLongAsItTakesIf the mutex is already locked, this determines how you want to respond. You can either stop the job immediately, wait for X seconds, or wait as long as it takes for the mutex to unlock. |
Default: StopImmediately |
| Seconds to wait for mutex | In | If you chose to wait a while in the parameter above, this determines how many seconds to wait until it is unlocked. | |
| Action if already locked | In | Choices: StopJobWithFailure, StopJobWithSuccessThis determines what you want this step to do if the mutex is locked (whether or not you want to return an error). |
Default: StopJobWithFailure |
| Log output level | In | Choices: Minimal, VerboseThe level of execution detail you want to appear in the log. |
Default: Minimal |
| Mutex GUID | Out | The GUID that identifies this mutex. |
(Italics = required parameters)
Notes
The [Files] Mutex Lock module can be used when various jobs might have the potential to interefere with each other if they were able to run at the same time. The lock allows the job which grabs a named lock first, to continue processing. If another job comes along while the first job is still running, and it wants to grabs a lock of the same name, the second job will be forced to wait until the first job finishes. As soon as the first job release the named lock, then the second job will immediately proceed with processing.
This is ideal when multiple jobs might be fighting for access to a specific resource. Or for performance reasons, you might want to limit certain types of jobs from running concurrently. An example of this might be two different jobs that want to make large changes to the same database table. Having the jobs wait for each other may significantly enhance processing speed.
After a job is fisnihed with a named lock, it should always use the corresponding [Files] Mutex Unlock as soon as it can.