From derby-user-return-10118-apmail-db-derby-user-archive=db.apache.org@db.apache.org Thu Nov 13 10:08:26 2008 Return-Path: Delivered-To: apmail-db-derby-user-archive@www.apache.org Received: (qmail 73001 invoked from network); 13 Nov 2008 10:08:26 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 13 Nov 2008 10:08:26 -0000 Received: (qmail 51898 invoked by uid 500); 13 Nov 2008 10:08:31 -0000 Delivered-To: apmail-db-derby-user-archive@db.apache.org Received: (qmail 51865 invoked by uid 500); 13 Nov 2008 10:08:31 -0000 Mailing-List: contact derby-user-help@db.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: List-Post: List-Id: Reply-To: "Derby Discussion" Delivered-To: mailing list derby-user@db.apache.org Received: (qmail 51854 invoked by uid 99); 13 Nov 2008 10:08:31 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 13 Nov 2008 02:08:31 -0800 X-ASF-Spam-Status: No, hits=-4.0 required=10.0 tests=RCVD_IN_DNSWL_MED,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: local policy) Received: from [192.18.6.21] (HELO gmp-eb-inf-1.sun.com) (192.18.6.21) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 13 Nov 2008 10:07:11 +0000 Received: from fe-emea-10.sun.com (gmp-eb-lb-2-fe2.eu.sun.com [192.18.6.11]) by gmp-eb-inf-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id mADA7hRL017435 for ; Thu, 13 Nov 2008 10:07:53 GMT Received: from conversion-daemon.fe-emea-10.sun.com by fe-emea-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0KA900G01L16CM00@fe-emea-10.sun.com> (original mail from Knut.Hatlen@Sun.COM) for derby-user@db.apache.org; Thu, 13 Nov 2008 10:07:43 +0000 (GMT) Received: from localhost ([129.159.112.134]) by fe-emea-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0KA9008YVO4F7Y40@fe-emea-10.sun.com> for derby-user@db.apache.org; Thu, 13 Nov 2008 10:07:28 +0000 (GMT) Date: Thu, 13 Nov 2008 11:07:26 +0100 From: Knut Anders Hatlen Subject: Re: Bugs? Deadlock detection with internal transactions, locking strategy when updating indices In-reply-to: <491B0ECC.90609@Sun.COM> Sender: Knut.Hatlen@Sun.COM To: Derby Discussion Message-id: Organization: Sun Microsystems MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT References: <011801c944e5$2fa82cc0$8ef88640$@edu> <491B0ECC.90609@Sun.COM> User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.0.60 (usg-unix-v) X-Virus-Checked: Checked by ClamAV on apache.org Kristian Waagan writes: > Jeff Stuckman wrote: >> Hello everyone, >> >> I just solved a hard-to-troubleshoot deadlock bug in my application. The >> fact that a deadlock occurred may or may not be a flaw in Derby, but the >> failure of the deadlock detection code to detect the cycle is probably a >> bug. I'm wondering if a knowledgeable person has time to read my analysis >> and advise if I should file a defect or not. >> >> Problem summary: >> Even using READ_COMMITTED, a single non-updatable SELECT and a single UPDATE >> statement can deadlock against each other when an index includes the updated >> column. The transactions fail due to a lock timeout and the deadlock is not >> detected, possibly because a transaction of type InternalTransaction is part >> of the cycle. >> > > Hello Jeff, > > First of all, thanks for your analysis and feedback. Much appreciated :) > > I'm sure someone with more knowledge in this area will try to answer > you questions, but your description made me think about a Jira issue > that has already been logged. Since you have written this description > and thought about the problem, maybe you could also find the time to > read the Jira issue and consider whether it is the same problem or > not? > > The issue is DERBY-2991 - Index split deadlock : > https://issues.apache.org/jira/browse/DERBY-2991 I agree, the problem Jeff described looks very much like DERBY-2991. The row locks on (XX,1) tell that the scan protection lock (a hybrid between an ordinary row lock and a page latch) is involved, which is a clear indication of DERBY-2991. > I'm aware of a fix being worked on for this issue, but I don't know > when it will be delivered. Right. I've done some investigation and have posted some ideas on how to fix it. I haven't received any negative feedback on the ideas, so I'll just go ahead an try to make the necessary changes. I don't have a clear picture yet of how much time it will take, though. -- Knut Anders