On Thu, Apr 12, 2012 at 7:14 AM, Alex Karasulu <email@example.com
> On Thu, Apr 12, 2012 at 4:35 PM, Emmanuel Lécharny <firstname.lastname@example.org
>> Forgot to reply to this mail, which raises interesting points.
>> More inside.
>> Le 4/11/12 10:38 PM, Alex Karasulu a écrit :
>>> On Wed, Apr 11, 2012 at 4:04 PM, Emmanuel
>>>> I think we should add some mechanism in the server to check that
>>>> automatically, to avoid doing it by hand (there are hundreds of tests to
>>>> check...). One solution would be to keep a track of every cursor
>>>> construction in a HashMap, and to remove them when the cursor is closed.
>>>> The remaining cursors are likely not closed.
>>> It would be nice to have a Cursor monitor that every opened Cursor
>>> registers with but this needs to happen automatically. Then when out of
>>> creation scope the Cursor is expected to be closed and if not this is
>>> handled automatically. However does creation scope work well since
>>> sometimes we create Cursors and pass them up?
>> We do have a monitor, which is currently used to check that the cursor is
>> not closed when we try to use it. We certainly can use this monitor for more
>> than just checking such thing.
>> Now, the pb is that the scope is not as easy to determinate than for a
>> variable in Java. For instance, if we consider persistent searches, or paged
>> searches, or even an abandonned search request, the scope is pretty wide...
>> Though we can have a set of rules that help us to close the cursor
>> automatically :
>> - if we get an exception during a SearchRequest, then the cursors must be
>> closed immediately. As soon as we store the cursors into the SearchContext,
>> this is pretty easy to do
>> - an AbandonRequest will close the cursor automatically too (getting the
>> cursor from the abandonned request)
>> - when we process the SearchResultDone, we can also close the cursor for
>> the current search request (this work for PagedSearch too)
>> - for pagedSearch, if the user reset the search by sending 0 as the
>> expected number of entries to return, then the cursor will be freed
>> - for persistent searches, as it will be closed by an unbind or an abandon
>> request, we are fine
>> - when a client unbinds, then all the pending cursors will be closed.
>> All in all, we have everything needed to close the cursors automatically,
>> assuming we keep all the cursors into the session.