Resource Consistency Configuration
|
TODO
This section needs to be expanded.
However, documentation work is similar to the development work in that it takes time and that it needs funding. |
The consistency section of Resource Configuration contains configuration of various data consistency mechanisms and features.
This may include configuration of high-level operation retries and similar technical configuration.
This section contains:
-
avoidDuplicateValues: When set to true, midPoint will try to avoid adding attribute values that are already there and remove values that are not there. Some resources do not tolerate such operations and they respond with errors. However midPoint cannot rely on transactions. MidPoint’s lock-free relativistic model provides the necessary consistency, occasional redundant additions or deletions may happen. If this option is turned on then midPoint will read the data from resource right before the operation and filter our any redundant changes. This requires additional operation and it increases the risk of inconsistencies. However it is the only practical option for some resources. -
caseIgnoreAttributeNames: If set to true then midPoint will ignore the case of the attribute names. In that case midpoint will normalize any attribute names with regard to the resource schema. -
postpone: -
discovery: -
connectorErrorCriticality: Specifies a method that midPoint will use to evaluate criticality of errors: which errors are considered to be critical (stops the operation) and which error are non-critical (operation continues). By default network errors are not considered critical, other errors are critical. EXPERIMENTAL: use with care.
Avoiding Duplicate Values
MidPoint usually operates in a relative way. Therefore midPoint does not look at the current account values very closely. What is important for midPoint is what attribute values are to be added or removed. Therefore it may happen that midPoint will try to add a value that is already present in the account. Or midPoint may try to remove values that are no longer in the account. Some resources can handle that situation without any problems. But other resources (LDAP server in particular) may return an error.
A solution is to use `avoidDuplicateValues`resource configuration property. If this feature is turned on then midPoint will try to read the account and avoid operations that would result in duplicate values. This approach usually works well. But, theoretically, it has two limitations:
-
Performace: midPoint will read the account once again right before the modification operation. This is needed to avoid duplicate changes.
-
There is still a tiny chance that two operations will change the same attribute at the same time and there may be an error. The critical time window is small (that is the reason to re-read the account right before the modify operation). But there is still a theoretical possibility.
But even avoidDuplicateValues is OK, despite the theoretical limitations. The avoidDuplicateValues feature is used often and so far we haven’t see any major issues in practice.