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: neutral (nike.apache.org: local policy)
Message-ID: <4807A344.2050509@volny.cz>
Date: Thu, 17 Apr 2008 21:21:40 +0200
From: Svata Dedic <garat@volny.cz>
User-Agent: Mozilla-Thunderbird 2.0.0.9 (X11/20080109)
MIME-Version: 1.0
To: Derby Discussion <derby-user@db.apache.org>
Subject: Re: Deadlock when getting DB metadata
References: <48065E5C.9010206@volny.cz> <x7prsp2wwn.fsf@ugle.localdomain>
 <48072574.9020009@volny.cz> <wjo8ej94ljxo.fsf@khepri41.norway.sun.com>
In-Reply-To: <wjo8ej94ljxo.fsf@khepri41.norway.sun.com>
Content-Type: text/plain; charset=ISO-8859-2
Content-Transfer-Encoding: 7bit

Knut Anders Hatlen wrote:
> There is one workaround you may try out: Right after you have created
> the database you can invoke DatabaseMetaData.getColumns() and any other
> meta-data calls you expect to use. Then the internal meta-data queries
> will be compiled and their execution plans stored in the database, so
> that you don't need to compile them at the point where you now see the
> deadlock. It is the (internal) compilation of the meta-data queries that
> causes the deadlock.
> 
The application attempts to read the DB schema right after it connects
to the database. Then, after DB schema change operation, it re-reads
some tables/indexes/foreign keys to keep the 'mental image' up-to-date,
using the same code (although limited to scan just some table(s) metadata).

In this situation, the DB already contained some tables when the app
started, so statements to discover exported/imported FKs, indexes,
column and table definitions were already processed and compiled at the
start, long before the operation that caused the deadlock was executed.

Is there a logger I can enable to see exact statements being compiled
internally ? I would like to verify the above, or at least discover
which type of commands are executed.

Thanks,
-Svata