Dynamic Subsets Lock Contention

Dynamic Subsets determine their members based on a MDX statements when the subset is read.  TM1 native views and MDX based views may reference a dynamic subset by name.  The evaluation of the list of members requires the dynamic subset to be write locked.  Attribute values are typically referenced in MDX statements to determine the list of elements.  

When a TM1 native view or MDX statement is evaluated the subset is write locked for the duration of the view construction, not just the time it takes to evaluate members in the subset.   The dynamic subset will remain write locked until cube data is displayed to the user.  During this time all other views or MDX statements that reference that dynamic subset (by name) must wait.  Consider cases where a view or MDX statement requires a significant amount of time to open because of size or complexity (rules derived and consolidated cells).  If many concurrent users are trying to access views that use the same dynamic subset, then construction of the views will be serialized.  This will leads to a delay for some users trying to retrieve data from the TM1 model.

Dynamic subsets are not recommended when the list of elements in the subset is not expected to change frequently.  If the MDX statement of the subset determine the list of elements in the subset based on attributes that are updated daily, then a static subset should be rebuilt daily, after the attributes are updated. 

Also, consider the case where a dynamic subset is based on element attributes, and the element attributes are rule derived.  In this case there may also be a performance impact due to evaluation of rules on the element attributes cubes.  If the attribute values do not need to be determined dynamically (don't frequently change) each time the attributes value is required, then static attribute values should be used instead of rules.