[
https://issues.apache.org/jira/browse/DIRSERVER-1642?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13086167#comment-13086167
]
Emmanuel Lecharny commented on DIRSERVER-1642:
----------------------------------------------
Kiran is right here, but we must assume that even if we delete some element in
the BTree, the cursor we have built on top of it should still be able to return
the correct next element, as it stores the current position.
I think the problem has more to do with the way we manipulate the cursor's
internal pointers than with the way JDBM deal with BTree modifications.
I will investigate this aspect anyway.
> Unexpected behaviour in JdbmIndex
> ---------------------------------
>
> Key: DIRSERVER-1642
> URL: https://issues.apache.org/jira/browse/DIRSERVER-1642
> Project: Directory ApacheDS
> Issue Type: Bug
> Reporter: Stefan Seelmann
> Attachments: IndexTest.java
>
>
> During my experiments and tests of removing one-level and sub-level indices
> at least one integration test "SearchAuthorizationIT" failed (the test fails
> recursivelyDelete()). A debugging session showed that the follwing:
> - in recursivelyDelete() multiple search requests are done which leads to
> multiple open cursors in the XDBM search engine
> - an entry is deleted
> - when the open cursors are advanced wrong/unexpected entries are returned
> I was able to create a small test that shows the problem:
> - the index contains six tuples:
> (a,1)
> (b,2)
> (c,3)
> (d,4)
> (e,5)
> (f,6)
> - a cursor over the index is created and advanced two times, the expected
> tuples (a,1) and (b,2) were returned
> - now tuple (c,3) is deleted
> - when the cursor is advanced again the tuple (b,2) is returned again! I had
> expected (d,4).
> Note that this doesn't happen with AvlIndex.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
