directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Norval Hope" <nrh...@gmail.com>
Subject Re: Implementing the PagedSearchControl
Date Wed, 03 Dec 2008 23:46:31 GMT
Hi,

I don't know the core code like you, but given my current
understanding (pardon me if my understanding is woefully inadequate
:-) I'm not sure your option 2 is really viable. After the first page
is returned, how are you going to initialize the cursor for the next
page? Wouldn't you have to remember where you were up to (using some
sort of unique per-result key) and rerun the search, skipping results
up to this key value (if so then it's unworkable no?). BTW Is there
guaranteed to be a stable sorting order for search results internally,
and is the sort control supported by AD so that it may be posed
externally etc.

At any rate I don't think keeping a cursor open is that big a deal,
although there probably needs to be a server-side timeout so that if
the cursor is not accessed for a long time (say an hour for argument)
it is automatically closed. Well behaved clients should explicitly
close their NamingEnumerations which I would hope would allow the
cursor to be discarded immediately.

Cheers

On Thu, Dec 4, 2008 at 10:25 AM, Emmanuel Lecharny <elecharny@gmail.com> wrote:
> Hi guys,
>
> I'm trying to implement this control for 1.5.5, and I'm a bit stuck in the
> way we should handle it in the core server. Right now, the control is
> decoded (the ASN.1 decoder has been written and tested, it works fine). The
> SearchHandler has been modified so that we can implement the control in only
> one case : the doSimpleSearch() method.
>
> The problem I have is the following : we have to remember the pointer to the
> last entry we have sent back to the client
>
> How should we do ? My first approach was pretty naive : we are using a
> cursor, so it's easy, we simply store the cursor into the session, and the
> next request will just have to get back this cursor from the session, and
> get the N next elements from this cursor.
>
> This has the advantage of being simple, but there are some very important
> cons :
> - it's memory consuming, as we may keep those cursor in the session for a
> very long time
> - we will have to close all the cursors when the session is closed (for
> whatever reason)
> - if some data has been modified since the cursor creation, it may contain
> invalid data
> - if the user don't send and abandon search request, those cursors will
> remain in the session until it's closed (this is very likely to happen)
>
> So I'm considering an alternative - though more expensive and less
> performant - approach :
> - we build a new cursor for each request,
> - we move forward the Nth entry in the newly created cursor, and return back
> the M requested elements
> - and when done, we discard the cursor.
>
> The pros are
> - we don't have to keep n cursors in memory for ever.
> - from the client POV, it respects the PagedSeach contract
> - it's easier to implement as we have less information to keep in the
> session, and to restore back
>
> The cons are :
> - it's time consuming, as if we have N entry to return, with a P page size,
> we will construct N/P cursors.
>
> Do you see a better way to implement this control, and if not, which one do
> you think is the best ?
>
> Thanks !
>
> --
> --
> cordialement, regards,
> Emmanuel L├ęcharny
> www.iktek.com
> directory.apache.org
>
>
>

Mime
View raw message