directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Emmanuel Lecharny (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (DIRSERVER-1642) Unexpected behaviour in JdbmIndex
Date Thu, 18 Aug 2011 07:40:27 GMT

    [ https://issues.apache.org/jira/browse/DIRSERVER-1642?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13086861#comment-13086861
] 

Emmanuel Lecharny commented on DIRSERVER-1642:
----------------------------------------------

I think it's a bit more complex than just using the Key in the Browser. IMO, the remove (or
add) operation must update the browser so that the call to a getNextTuple or getPreviousTuple
still return the correct value. One idea would be to retain the last returned key, so that
we can reinitialize the index. There is a corner case though for a delete : if the removed
element is the last returned one, we must have a way to set the correct position by using
the key we returned two calls before.

And i'm afraid it's not enough : for big indexes, the BTree will be span on multiple BPage,
and during the remove operation, we don't have access to the browser.

Removing an element in a BTree while browsing it seems a bad idea...

Otherwise, the ultimate solution is to drop JDBM and to use a MVCC system, where elements
are not deleted when in use. But this is another story...

> 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

        

Mime
View raw message