db-derby-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Knut Anders Hatlen <Knut.Hat...@Sun.COM>
Subject Re: Deadlock when getting DB metadata
Date Thu, 17 Apr 2008 12:55:47 GMT
Svata Dedic <garat@volny.cz> writes:

> Knut Anders Hatlen wrote:
>> Svata Dedic <garat@volny.cz> writes:
>>> 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.
>> hile
>> 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
> Thanks. Yes, indeed the operation completes successfully, but the delay
> has deadly impact on user experience with the application.
>  The issue #177 talks about transactions and subtransactions (spawned
> internally by the statement compilations) - in my case, there should be
> no outer transaction (autocommit = on) at the time metadata is
> requested. Dumb question: does the issue apply even to this scenario
> (DatabaseMetadata called without turning autocommit to false) ?

Hi Svata,

Yes, the issue applies since you also have transactions when auto-commit
is turned on. The difference between auto-commit on and auto-commit off
isn't whether or not you have transactions, but whether or not the
transactions are automatically committed when a statement is completed.

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.

Knut Anders

View raw message