Simple paged results

Use this information to work with the simple paged results.

Simple Paged Results provides paging capabilities for LDAP clients that want to receive just a subset of search results (a page) instead of the entire list. The next page of entries is returned to the client application for each subsequent paged results search request. The request is submitted by the client until the operation is canceled or the last result is returned. The server ignores a simple paged results request if the page size is greater than or equal to the sizeLimit value for the server because the request can be satisfied in a single operation.

Because paging of search results holds server resources throughout the life of the simple paged results request, several new administrative limits that are employed to ensure that server resources cannot be abused, or misused, by using simple paged results search requests.

ibm-slapdPagedResAllowNonAdmin

By default, the server accepts requests from non-administrator binds, including those bindings anonymously. If you want the server to accept simple paged results search requests only from users that bind with administrator authority, you need to change the following line in the ibmslapd.conf file:

ibm-slapdPagedResAllowNonAdmin: true to ibm-slapdPagedResAllowNonAdmin: false

See Search Settings. If the line does not exist, add it with a value of false to allow only Administrator bind.

ibm-slapdPagedResLmt

By default, the server allows a maximum of three outstanding simple paged results operations at any time. To ensure the fastest response for subsequent simple paged results request, the server holds a database connection open throughout the life of the search request until the user cancels the simple paged results request, or the last result is returned to the client application. This administrative limit is designed to ensure that other operations that are being handled by the server are not denied service because all database connections are in use by outstanding simple paged results search requests. For consistent results, set the ibm-slapdPagedResLmt value lower than the maximum number of database connections for your server. To change the value of this administrative limit, change the following line in the ibmslapd.conf file.

ibm-slapdPagedResLmt: 3

See Search Settings. If the line does not exist, add it to set the new maximum (if the line does not exist, the server is using the default value).

ibm-slapdIdleTimeOut

The idle timeout administrative limit is designed to age out DB2® database connections held open for simple paged results search requests. The default idle time for a simple paged results request is 500 seconds. For example, if a client application were to pause for 510 seconds between pages, the server might age out the request to free the database connection for use by other server operations. The server returns the appropriate error to the client application for the next simple paged results request submitted. This point is where the client application needs to restart the simple paged results request. The idle timer for each simple paged results request is restarted after every page returned to the client application. The server checks for aged out simple paged results request every 5 seconds. So, if you set the value of ibm-slapdIdleTimeOut value lower than 5 seconds, you still must wait 5 seconds for the simple paged results requests to be aged out. To change the value of this administrative limit, change the following line in the ibmslapd.conf file.

ibm-slapdIdleTimeOut: 300

See Search Settings. If the line does not exist, add it to set the new maximum (if the line does not exist, the server is using the default value).

The LDAP server returns all referrals to the client at the end of a search request, the same as a search without any controls. That means that if the server has 10 pages of results that are returned, all the referrals are returned on the 10th page, not at the end of each page. When you chase referrals, the client application needs to send in an initial paged results request, with the cookie set to null, to each of the referral servers. It is up to the application that uses the client services to decide whether to set the criticality as to the support of paged results, and to handle a lack of support of this control on referral servers as appropriate based on the application. Additionally, the LDAP server does not ensure that the referral server supports paged results controls. Multiple lists might be returned to the client application, some not paged. It is at the decision of the client application as to how to best present this information to the user. Possible solutions include these aspects:

Combine all referral results before they are present to the user
Show multiple lists and the corresponding referral server host name
Take no extra steps and show all results to the user as they are returned from the server

The client application must turn off referrals to get one truly paged list, otherwise when you chase referrals with the paged results search control specified, unpredictable results might occur.

More information about the server side simple paged results control can be found in RFC 2686. The control OID for simple paged results is 1.2.840.113556.1.4.319, and is included in the Root DSE information as a supported control.

If paging is supported on backend servers, then the proxy server also supports page control and register the control in its root DSE. However, the proxy server does not verify the ibm-slapdPagedResAllowNonAdmin and ibm-slapdPagedResLmt values of the backend servers. It is the responsibility of the administrator to keep the values in sync. Any error that is returned by backend server because of difference in value of the two attributes is considered an error and are returned to the client.