There are four iteration methods (see
|Fetches objects in single DB transaction. Not supported for all DBMSs. For those that support it (e.g. PostgreSQL) it can lead to long-running transactions spanning hours or even days. Moreover, current transaction isolation settings cause the objects returned to have values that were stored in the database when the search was initiated.|
Uses the "simple paging" method: takes objects (e.g.) numbered 0 to 49, then 50 to 99, then 100 to 149, and so on. The disadvantage is that if the order of objects is changed during operation (e.g. by inserting/deleting some of them) then some objects can be processed multiple times, where others can be skipped.
|Uses the "strictly sequential paging" method: sorting returned objects by OID. This is (almost) reliable in such a way that no object would be skipped. However, custom paging cannot be used in this mode, except for setting |
This is a workaround for situations when
So this method is a safe fallback that is used when
Before midPoint 3.9
Before 3.9, majority of iterations were done in this mode - unless configured otherwise (globally in
config.xml or per individual searches):
After midPoint 3.9
In 3.9 we changed the default settings so the iteration is done like this:
Elimination of long-running transactions could lead to a better performance and freshness of data (
MID-4414Getting issue details...
means that custom paging cannot be used, except for
maxSize parameter. In stock midPoint, we typically don't use paging combined with
searchObjectsIterative method. But if you have a custom code, e.g. in scripts, make sure you either replace
searchObjects, eliminate the paging (except for
maxSize), or change the default iteration method (see below).
If an iterative search encounters a combination of implicitly-set
and non-compatible custom paging, it:
- If the custom paging has
500(or the current value of
maxObjectsForImplicitFetchAllIterationMethodsystem parameter), then switches iteration method to
- Otherwise it issues an warning message to the log and switches iteration method to
In particular, beware of bulk actions (midPoint scripting). Searching objects there uses
Influencing the iteration method
repository.searchObjectsIterative operation, selection of iteration method is done using the following parameters:
GetOperationOptions.iterationMethodis specified, it is used without any further considerations.
- Otherwise, the repository configuration determines whether to use
STRICTLY_SEQUENTIAL_PAGING. (Up to midPoint 3.9 the default was to use transaction for PostgreSQL, Oracle and SQL Server and to use paging for MySQL/MariaDB and H2. Since 3.9, the default is to use paging for all databases.)
- In the latter case, the
strictlySequentialflag decides between
true). Up to midPoint 3.9, the value of this flag was mostly
false. Since 3.9, it is
trueat all the places in midPoint code.
strictlySequential flag is not present on
model.searchObjectsIterative operation, however. If you call that operation (as you usually do), the only way how to choose the iteration method by the caller is to use
As a special case, for abstract search iterative tasks,
mext:iterationMethod extension property (
) is used to provide the
GetOperationOptions.iterationMethod value to the main