Difference between revisions of "Paged Results"

(Real world example)
(Previous behaviour)
Line 7: Line 7:
 
= Previous behaviour =
 
= Previous behaviour =
  
RFC2696 does not specify how an implementation should behave in the case of simultaneous modification.
+
RFC2696 does not specify how an implementation should behave in the case of simultaneous modification. Before Samba 4.10, results were temporarily saved in memory and were fed back the client as required.
  
 
= Real world example =
 
= Real world example =

Revision as of 01:23, 1 March 2019

For Samba 4.10, the behaviour of the paged results control (1.2.840.113556.1.4.319, RFC2696) has been changed to more closely match Windows servers, to improve memory usage. Paged results may be used internally (or is requested by the user) by LDAP libraries or tools that deal with large result sizes, for example, when listing all the objects in the database.

Previously, results were returned as a snapshot of the database but now, some changes made to the set of results while paging may be reflected in the responses. If strict inter-record consistency is required in answers (which is not possible on Windows with large result sets), consider avoiding the paged results control or alternatively, it might be possible to enforce restrictions using the LDAP filter expression.

Previous behaviour

RFC2696 does not specify how an implementation should behave in the case of simultaneous modification. Before Samba 4.10, results were temporarily saved in memory and were fed back the client as required.

Real world example

Although the consistency has been changed, realistically most clients will not see any impact. Paged results normally cause a stream of requests to happen in rapid succession, leaving little time to modify the database in between. Besides full searches, attributes of interest should not be changed all that frequently to begin with.

Independent issues

External race conditions