From derby-dev-return-66591-apmail-db-derby-dev-archive=db.apache.org@db.apache.org Tue Mar 03 10:35:18 2009 Return-Path: Delivered-To: apmail-db-derby-dev-archive@www.apache.org Received: (qmail 72899 invoked from network); 3 Mar 2009 10:35:17 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 3 Mar 2009 10:35:17 -0000 Received: (qmail 39358 invoked by uid 500); 3 Mar 2009 10:35:17 -0000 Delivered-To: apmail-db-derby-dev-archive@db.apache.org Received: (qmail 39327 invoked by uid 500); 3 Mar 2009 10:35:17 -0000 Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: Delivered-To: mailing list derby-dev@db.apache.org Received: (qmail 39318 invoked by uid 99); 3 Mar 2009 10:35:17 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 03 Mar 2009 02:35:17 -0800 X-ASF-Spam-Status: No, hits=-2000.0 required=10.0 tests=ALL_TRUSTED X-Spam-Check-By: apache.org Received: from [140.211.11.140] (HELO brutus.apache.org) (140.211.11.140) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 03 Mar 2009 10:35:16 +0000 Received: from brutus (localhost [127.0.0.1]) by brutus.apache.org (Postfix) with ESMTP id 23A05234C4B2 for ; Tue, 3 Mar 2009 02:34:56 -0800 (PST) Message-ID: <1366011416.1236076496144.JavaMail.jira@brutus> Date: Tue, 3 Mar 2009 02:34:56 -0800 (PST) From: "Knut Anders Hatlen (JIRA)" To: derby-dev@db.apache.org Subject: [jira] Created: (DERBY-4080) Possible deadlock between locks and latches in BTreeController.compareRowsForInsert() MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org Possible deadlock between locks and latches in BTreeController.compareRowsForInsert() ------------------------------------------------------------------------------------- Key: DERBY-4080 URL: https://issues.apache.org/jira/browse/DERBY-4080 Project: Derby Issue Type: Bug Components: Store Affects Versions: 10.4.2.0 Reporter: Knut Anders Hatlen It looks like BTreeController.compareRowsForInsert(), which is used to check for duplicates in a unique nullable index, can run into a deadlock which involves both locks and latches. Here's what I think can happen: comparePreviousRecord() (or compareNextRecord()) holds a latch on the index page where a new row is about to be inserted, and needs to check if there's a duplicate on one of the adjacent rows. Because the row is near a page boundary, this check moves to another index page, while still holding the latch on the original index page. Then compareRowsForInsert() is called, which tries to get an update lock on the existing row. If it has to wait for the update lock, the latch on the current page is released, but the latch on the original index page is kept. This means that the transaction is holding a latch while it is waiting for a lock, which means that it is blocking all access to that page until it has been granted the lock. If some other transaction that is holding a conflicting lock on the row later needs to latch the index page, those two transactions run into a deadlock and the one that's waiting for the lock will eventually time out (but it will not be reported as a deadlo ck). If compareRowsForInsert() releases all latches when it needs to wait for a lock, the deadlock is prevented, and both of the transactions may be able to complete without timing out. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.