Interesting thread...
I must say that on the first for points, you are just spot on.
We discussed that with Alex this morning, and we may have overlooked the
impacts, thus the proposed "solution".
Le 5/10/12 7:18 PM, Selcuk AYA a écrit :
As for the paged search, one way to deal with it would be to read all
the data from the cursors at the beginning of the paged search and
close the cursor.
That was an option we also discussed, but we found it extremely costly.
Sadly, i'm afraid that this is the only viable solution...
This would be similar to a normal search.
Well, normal searches don't do that. They fetch the entries one by one,
using a cursor over an index that may not be valid when we fetch teh
entries.
That means we also have to make a normal search fetch all the entries...
If we get
worried about memory consumption of this, the entries to be returned
could be spilled over to temp files.
That's certainly something we can do. We can even store the data into a
JDBM HTree, temporarily.
You might say this might lead to
temp file that are never claimed but if there are not many of them
then no big deal.
No, that's something we can handle easily.
Users are supposed to deal with cleaning up their
contexts.
Hmm, well, you know, users are... users :)
Anyway, as of today, I have cut the 2.0.0-M7 release (yeah!), will start
a vote on it, and we will have plenty of time to discuss the best
possible solution for this critical search issue. We can even postpone
this to 2.0.0-M8, because I think that it's way more critical atm to
merge your branch into trunk.
All in all, we are aware that there is a problem, even if the proposed
solutions are not sane, atm.
That's just plain good...
Many thanks !
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
