[ApacheDS] LDAP Prepared Filters

[Alex Karasulu <ak...@apache.org>]

Yet another idea ...

Constructing a Cursor for a filter imposes some overhead in search which
imposes some latency before the first entry is even returned.  When the same
filter with different assertion values are used frequently in search
operations that return a small set of entries this latency could be a major
factor in determining search rates.  What if we can parameterize filters as
suggested in the previous thread on filter indices:

(& (objectClass=person) (ou=?) (l=?))

Presume we implement a special search request control called prepare
filter.  This search would return immediately without results.  The request
would build a special kind of parameterized Cursor matching those of the
filter.  The Cursor is kept in a cache which associates the filter with the
Cursor.  The search result done response with SUCCESS would indicate filter
preparation succeeded, while a special result code for statement preparation
failure could be used to denote errors.

When normal search requests are received the Cursor cache is consulted to
quickly pull out and deep clone this Cursor.  The cloned Cursor copy's
parameter values are set for the ou and localityName attributes.  Then the
Cursor is used to conduct the search.  This ***could*** be cheaper than
building the Cursor (the search plan) from scratch by analyzing the filter
AST.

If this latency can be removed a big impact on search request rates can be
felt especially when the same search is performed repeatedly to return a
small number of results.  I've seen this happen a lot in real world
scenarios.  I've seen many frequent one level scoped searches using the same
filter with different values to return a small set of entries or just a
single entry.

Thoughts?

Alex