Page History
This activity acquires an exclusive lock using a specified identifier. It can be used (in conjunction with the MUTEX_RELEASE activity) to implement "single-threaded" access to a specified "resource", or, to put it another way, to block concurrent usage of the "resource".
For example, you may need to invoke a third-party provided web service that requires authentication, but permits only one concurrent request. If you need to implement this web service in your BPI solutions, then the MUTEX_ACQUIRE and MUTEX_RELEASE activities can be used (surrounding the web-service call) to ensure that only one active process attempts to invoke the web service, while any other concurrent process attempting to do so either waits or treats the unavailability as an exception accordingly.
...
When implementing MUTEX_ACQUIRE, the possibility arises of unanticipated circumstances leading to affected processes being unexpectedly "blocked" from normal operation. You need to understand this and plan procedures to free locks that inadvertently remain. In the simplest instance you can immediately free a lock by running the MUTEX_RELEASE activity - if you wish, you can do this directly from the LANSA Composer client (it does not have to be included in a processing sequence, but can be run on its own). In these circumstances, you will normally need to specify *YES for the FORCERELEASE parameter.
...
2. When implementing the MUTEX_ACQUIRE activity, we advise that you always "pair" it with a corresponding MUTEX_RELEASE activity surrounding the Processing Sequence directives and activities (as closely as possible) that comprise the conceptual resource you are seeking to protect. Options are available for automatic release of the locks - refer to the description of the DURATION parameter – but we advise that you do not rely on these exclusively, but include the MUTEX_RELEASE activity as early as possible to explicitly free the lock.
...
The identifier you use with MUTEX_ACQUIRE (and MUTEX_RELEASE) is a purely conceptual identifier – it does not represent any "real" system object or resource. However, it is your responsibility to devise and use an appropriate naming convention that will prevent unintended contention arising from using the same identifier for different purposes or resources.
...