Mailing-List: contact derby-user-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Derby Discussion" <derby-user@db.apache.org>
Received-SPF: pass (nike.apache.org: local policy)
Date: Thu, 17 Apr 2008 01:38:16 +0200
From: Knut Anders Hatlen <Knut.Hatlen@Sun.COM>
Subject: Re: Deadlock when getting DB metadata
In-reply-to: <48065E5C.9010206@volny.cz>
Sender: Knut.Hatlen@Sun.COM
To: Derby Discussion <derby-user@db.apache.org>
Message-id: <x7prsp2wwn.fsf@ugle.localdomain>
Organization: Sun Microsystems
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT
References: <48065E5C.9010206@volny.cz>
User-Agent: Gnus/5.110007 (No Gnus v0.7) Emacs/22.1 (usg-unix-v)

Svata Dedic <garat@volny.cz> writes:

> Hello,
>
> I am new to this list - so please accept my apologies if I ask something
> well known (I did a keyword google/list search with no reasonable results)
>
> I have the following issue: my code changes DB structure (create a
> column), then immediately after setting autocommit back to true, the
> code rescans the DB metadata
> 	DatabaseMetaData.getColumns(catalog, schemaName, tableName, null);
>
[...]
> I am sometimes getting a deadlock with these operations:
> I am quite positive that, at the time, no other threads access the
> database (and there are no pending DB operations on the threaddump while
> waiting on the lock).
>
> I've seen the deadlock occur during several get-metadata operations
> (getImportedKeys, ...), each time waiting on the SYSSTATEMENTS
> apparently because of internally constructed PreparedStatement.
>
> Can anyone give me pointers how to solve or avoid these issues ? I am
> able to reproduce this rather reliably, so any guidance what to test,
> what to debug or log in order to pinpoint the bug would be most appreciated.

Do the deadlock exceptions propagate out to your code, or do you only
see them in derby.log? I know that there is some code in that area that
may cause internal deadlocks or timeouts, but it successfully recovers
from the errors and doesn't expose the exceptions to the users. When
that happens, you may experience that your application hangs for a while
before it successfully continues, but the deadlock may still be logged
in derby.log. That bug is tracked here:
https://issues.apache.org/jira/browse/DERBY-177

-- 
Knut Anders