db-derby-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Dudgeon <tdudg...@informaticsmatters.com>
Subject Re: Deadlock when getting DB metadata
Date Sun, 04 May 2008 10:12:51 GMT
Any ideas on this issue?
The problem seems to have been identified.
Does anyone have suggestions for a fix or workaround?

Tim

Svata Dedic wrote:
> Hi,
> 
>> 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
> 
> thanks for the hint - I debugged the application a little and noticed a
> strange thing. After the start, a series of begin/end/execute prepared
> statements is printed:
> 
> ---------%<-----------------------%<--------------
> Begin compiling prepared statement: EXECUTE STATEMENT SYS."getColumns"
> :End prepared statement
> End compiling prepared statement: EXECUTE STATEMENT SYS."getColumns"
> :End prepared statement
> 
> Executing prepared statement: EXECUTE STATEMENT SYS."getColumns" :End
> prepared statement with 4 parameters begin parameter #1: % :end
> parameter begin parameter #2: APP :end parameter begin parameter #3:
> XXXXX :end parameter begin parameter #4: % :end parameter
> ---------%<-----------------------%<--------------
> 
> When the deadlock occurs, the "real" SQL into systables is beign
> compiled (I traced this sql to be the value of "getColumns" key in
> org/apache/derby/impl/jdbc/metadata.properties file):
> ---------%<-----------------------%<--------------
> Begin compiling prepared statement: SELECT CAST ('' AS VARCH
> AR(128)) AS PKTABLE_CAT, S.SCHEMANAME AS PKTABLE_SCHEM, TABLENAME AS
> PKTABLE_NAME, COLS.COLUMNNAME AS PKCOLUMN_NAME, CAS
> T ('' AS VARCHAR(128)) AS FKTABLE_CAT, FKTABLE_SCHEM, FKTABLE_NAME,
> FKCOLUMN_NAME, CAST ...
> ---------%<-----------------------%<--------------
> 
> For some reason, isUpToDate() on the getColumns() statement becomes
> false and the statement is recompiled.
> 
> So - doing all queries at the start does not help: they are recompiled
> during the DB usage anyways :-/
> 
> Any other idea for workaround or fix ?
> 
> Thanks for all the help so far,
> -Svata
> 
> Dag H. Wanvik wrote:
>> Svata Dedic <garat@volny.cz> writes:
>>
>>> 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.
>> You can enable trace with this setting in derby.properties:
>>
>> derby.language.logStatementText=true
>>
>> You can find the trace in derby.log.
>>
>> Dag
>>
>>
>>
> 


Mime
View raw message