Return-Path: Delivered-To: apmail-db-derby-dev-archive@www.apache.org Received: (qmail 95194 invoked from network); 15 Jul 2009 13:19:30 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 15 Jul 2009 13:19:30 -0000 Received: (qmail 21559 invoked by uid 500); 15 Jul 2009 13:19:39 -0000 Delivered-To: apmail-db-derby-dev-archive@db.apache.org Received: (qmail 21535 invoked by uid 500); 15 Jul 2009 13:19:39 -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 21527 invoked by uid 99); 15 Jul 2009 13:19:39 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 15 Jul 2009 13:19:39 +0000 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; Wed, 15 Jul 2009 13:19:36 +0000 Received: from brutus (localhost [127.0.0.1]) by brutus.apache.org (Postfix) with ESMTP id DF52B234C004 for ; Wed, 15 Jul 2009 06:19:14 -0700 (PDT) Message-ID: <859688967.1247663954899.JavaMail.jira@brutus> Date: Wed, 15 Jul 2009 06:19:14 -0700 (PDT) From: "Knut Anders Hatlen (JIRA)" To: derby-dev@db.apache.org Subject: [jira] Commented: (DERBY-4302) Deadlock on system tables In-Reply-To: <524214963.1247468954863.JavaMail.jira@brutus> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 X-Virus-Checked: Checked by ClamAV on apache.org [ https://issues.apache.org/jira/browse/DERBY-4302?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12731430#action_12731430 ] Knut Anders Hatlen commented on DERBY-4302: ------------------------------------------- It looks like the deadlock is between a CREATE TABLE statement and a SELECT statement against the table that is about to be created. Issuing such statements concurrently is very likely to break. With slightly different timing, it could just as well have failed with a "table CORE_FILE does not exist" error instead of a deadlock. > Deadlock on system tables > ------------------------- > > Key: DERBY-4302 > URL: https://issues.apache.org/jira/browse/DERBY-4302 > Project: Derby > Issue Type: Bug > Components: SQL > Reporter: Egidijus > > Using 3d part libraries which uses embedded Derby DB, I got following stack trace which shows that deadlock appears between *system* tables (unfortunately there are no code to reproduce). Connecting without auto commit and DB is used by two users: > Lock : TABLE, SYSCOLUMNS, Tablelock > Waiting XID : {9404, IS} , APP, SELECT cdo_version, cdo_created, > cdo_revised, cdo_resource, cdo_container, cdo_feature, name, id FROM > core_File WHERE cdo_id= ? AND (cdo_revised = 0 ) > Granted XID : {7351, IX} > Lock : ROW, SYSTABLES, (2,14) > Waiting XID : {7351, X} , APP, CREATE TABLE core_File (cdo_id BIGINT > NOT NULL, cdo_version INTEGER NOT NULL, cdo_class BIGINT NOT NULL, > cdo_created BIGINT NOT NULL, cdo_revised BIGINT NOT NULL, cdo_resource > BIGINT NOT NULL, cdo_container BIGINT NOT NULL, cdo_feature INTEGER > NOT NULL, name VARCHAR(32672), id VARCHAR(32672)) > Granted XID : {9404, S} > . The selected victim is XID : 9404. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.