Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Message-ID: <1369150588.1250589494799.JavaMail.jira@brutus>
Date: Tue, 18 Aug 2009 02:58:14 -0700 (PDT)
From: "Knut Anders Hatlen (JIRA)" <jira@apache.org>
To: derby-dev@db.apache.org
Subject: [jira] Commented: (DERBY-4081)
 BTreeController.comparePreviousRecord() may fail to release latch on
 left-most leaf
In-Reply-To: <1523407094.1236078176490.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/DERBY-4081?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12744438#action_12744438 ] 

Knut Anders Hatlen commented on DERBY-4081:
-------------------------------------------

Thanks for the reminder, Rick.

I think I've found a way to expose this problem now. Just continuously executing "insert into t(x) values 0" followed by "delete from t", where T.X is unique nullable and with auto-commit off, consistently hangs on the 372nd iteration.

On 10.5.1.1 that repro fails with a WaitError (DERBY-4097). It does not expose the problem on 10.4.2.0 or earlier since DERBY-4028 hides the problem by stopping the check for duplicates too early.

> BTreeController.comparePreviousRecord() may fail to release latch on left-most leaf
> -----------------------------------------------------------------------------------
>
>                 Key: DERBY-4081
>                 URL: https://issues.apache.org/jira/browse/DERBY-4081
>             Project: Derby
>          Issue Type: Bug
>          Components: Store
>    Affects Versions: 10.4.2.0
>            Reporter: Knut Anders Hatlen
>            Assignee: Knut Anders Hatlen
>         Attachments: derby-4081-1a.diff
>
>
> If comparePreviousRecord() is called on some other leaf page than the left-most leaf, and all the rows to the left of the current position are deleted so that the position is moved all the way to slot 0 on the left-most leaf, comparePreviousRecord() will return without releasing the latch on the left-most leaf. Only the leaf on which comparePreviousRecord() is called should be latched when the method returns.
> Since comparePreviousRecord() currently fails to continue after finding a deleted row, this bug is not possible to expose until DERBY-4028 is fixed.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.