What's Mutexes [sys_mutex] and why it's used in ServiceNow.

Community Alums
Not applicable
‎04-30-2024 04:13 AM

This article talks about Mutexes (sys_mutex) and its uses in ServiceNow. Consider a scenario when update set deployment is not working and you came across below error:

 

"You are not able to retrieve OR commit update sets in <instance> and getting the below message. 

Error: Update set preview and commit are unavailable because another operation is running: <Operation Name>

 

Tables in scope of this doc:

  1. Slow Mutex [sys_mutex_pattern] extends table Slow Pattern [sys_pattern]
  2. Mutex [sys_mutex]

Slow Mutex:

Administrators can use slow mutex logs to gain insight into how mutex locks are affecting platform performance.

Link Slow Mutex lock record details 

 

What is Mutex and relevance of mutexes<sys_mutex> table?

 

A mutex is a specific type of binary semaphore that provides a locking mechanism. It stands for Mutual Exclusion Object, and it ensures that only one thread can enter a critical section of code at a time. Mutexes can be shared by multiple processes. 
 

A mutex is a mutual exclusion lock that prevents multiple threads from accessing the same shared resource simultaneously. Mutexes are used to protect data or other resources from concurrent access.

 

Property "com.glide.hub.flow_engine.mutex_expiration" can be extended to a large value without any issues. However, long running flows are not recommended, and it is better to break flows up into smaller re-usable components. 
 

Use Case: When Mutex should be referred?

When any app/plugin installation was initiated or any update set was committed though not completed & cancelled after some time, then the 'update-mutex' entry gets created under sys_mutex.LIST table. If any application installation was cancelled after initiation, you might see this issue.

 

To resolve the issue we have to delete the entry that will resolve the issue as system is under impression that there is some installation is going on and hence it is not allowing you to retrieve preview or commit the update set.


To resolve the issue, please follow the below steps.

  1. Navigate to "sys_mutex.LIST"
  2. Search for the record "update-mutex"
  3. Delete the record from the "sys_mutex" table
    https://<instance.service-now.com>/sys_mutex_list.do?sysparm_query=nameLIKEupdate-mutex&sysparm_view...

 

Scope and more...

In ServiceNow, a mutex is taken against a Quick API context ID for quick flows and against sys_flow_context for every non-Quick flow execution. A mutex expires when a flow step execution time exceeds the value of the property set in "com.glide.hub.flow_engine.mutex_expiration". When this happens, the flow restarts from the last quiescence point, which is a point where a flow goes into a waiting state.

 

KB1640994 

By default, system property 'com.glide.hub.flow_engine.mutex_expiration' is not visible on the 'sys_properties' tables.

The default value of this system property by release version is as below:

Vancouver - 900 seconds
Washington DC - 3600 seconds 

  • Is there any potential negative effect of extending the system property 'com.glide.hub.flow_engine.mutex_expiration' to a large value?
    • There shouldn't be any issues with that
  • Any other steps that can be taken to avoid mutex expiration?
    • We generally do not recommend long running flows.  We recommend breaking flows up in to smaller re-usable components.  See more details
  • Is the time configured in 'com.glide.hub.flow_engine.mutex_expiration' compared to the time from where the flow starts, or from where the last quiescence point is? 
    • It's from the time the mutex is taken - so it's when the flow starts or resumes from a quiescence point
    • For example, if a flow consisted of an Ask For Approval action, the mutex expiration after the Approval is from when the Approval is completed rather than when the flow itself is started

References:

  • 4,242 Views
Popular Blog Posts