About Rule Precedence
Rules can conflict with one another and rules of the same type can co-exist. For example:
• The TDV Server will choose to implement the most specific rule over a more restrictive rule.
• In the absence of a specific rule on a resource, more restrictive rule is picked among rules of same rule type but different filter limits.
When certain 3rd party clients execute WLM, messages and sometimes actions are captured in the data result set. (e.g.: JDBC, ODBC, ADO.NET, SOAP and REST.)
For JDBC clients, we use SQLWarning.
For SOAP, warnings are returned via a SOAP fault.
For REST, can be returned via a "warnings" json element.
When queries are run against multiple published resources that have WLM rules defined for them, conflicts between the rules defined for each resource can occur. For example, emp_view has a full table scan rule defined and salary_view has a row limit rule defined, when a query is run that selects data from both emp_view and salary_view, the different rules cause conflicts in how the query would normally run. Some of these conflicts can be avoided by understanding the order in which rules are given precedence during conflicts. Conflicts arise when two rules apply to the same resource for the same user, and have different filter definitions, or different action types.
• Full table scans and Cross joins are the first rules to be checked.
• Rules with exception actions are executed last.
• When maxRowLimit is conflicting the more restrictive rule is used.
• When full table scans are set to true in only one of the rules, the rule in which the full table scan is true is used.
• When cross joins are set to true in only one of the rules, the rule in which the cross join is true is used.
• When maxRequestTime and maxRequestTimeUnit conflict in two rules, the more restrictive rule is used.
• When different resources have different memoryLimitPercentage rules for the same user, the most restrictive rule is used.
• When global rules (with null resource assignments) co-exist with specific rules on resources r1, r2 : For r1 ad r2, the specific rule is picked and for all other resources, the global rule is used.
• Multiple rules can co-exist on resources and its descendants. In that case, the rule on the descendants is considered a more specific rule compared to a rule on the parent resource.
• When global rules (with null member assignments) co-exist with specific rules on users u1, u2: For u1, u2, the specific rule is picked and for all other users, the global rule is used.
• A user can have multiple group memberships. If two rules exist on different groups, but applicable to the same user u1, the most restrictive rule is picked for the user on the specific resource.
• When action types, filters, resources or member assignments are different, then the rules are allowed to be created and the most effective, restrictive, or specific rule is chosen at runtime during rule violation checks.
• When action type differs for two rules, with the same filters and same resource/member assignments, and one of those rules already exists, the second rule will not be allowed to be created. An error will be encountered, indicating the conflict.
• Duplicate rules cannot be created. Similarly updating an existing rule to look identical to another existing rule is not allowed.
• TDV Manager Workload Management page has an option to view effective rules for any user. Users with WLM permission can perform this operation.
• The WLM rule types given below are applicable when the following resources are published as webservcies
- /services/webservices/publishTable – All rules are applicable.
- /services/webservices/publishView - All rules are applicable.
- /services/webservices/publishTransformation – Only “Row Limit, Request life time and Memory Lim it” are applicable.
- /services/webservices/published_script - Only “Row Limit, Request life time and Memory Limit” are applicable.
- /services/webservices/Published_package query - Only “Row Limit, Request life time and Memory Limit” are applicable.