Re: back-bdb

["Kurt D. Zeilenga" <Kurt@OpenLDAP.org>]

At 09:34 PM 2001-11-13, Debajyoti Bera wrote:
> I was trying to look at paged-based result for back-bdb. From the
>current code I found that in back-bdb for searching we have an array
>called candidates[] which stores currently the range of ids in which to
>search (and as replied in an earlier posting, will probably later contain
>the ids of possible candidates) and an ID cursor. Now it seems to me that
>one needs to store at least 'cursor' for implementing paged-based search.
>Also as candidates[] would govern the candidates over which 'cursor'
>should range, storing candidates[] would be good. But candidates is a huge
>array (64K) and so it would have too much overhead. Thus it seems that the
>cursor is only stored and everytime the request for next set arrives,
>candidates[] is recalculated and then search starts from the cursor. Won't
>this recalculation of candidates[...] everytime cause an overhead ? Or is
>there something which I am missing ... ?

I would suggest that for simple paged results, we remember
the candidate list and the cursor.  Generating the candidate
list repeatedly is, generally, too expensive.  I also suggest
we place significant restrictions on the number of current
simple paged result requests a client can make.  I suggest we
use a simple array to hold pointers to the state information
(in the connection structure).  The array size should be
determined from a macro, initial value of 2 seems reasonable.
The cookie can be derived from the array index.  Be sure when
locating the state information based upon the cookie you don't
trust the client in return valid cookies. Be sure to zap state
information upon bind (and other "to anonymous" cases).

Also, suggest you first implement this for back-ldbm then port
to back-bdb.