You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-dev@db.apache.org by "Richard N. Hillegas (Jira)" <ji...@apache.org> on 2020/01/12 19:22:00 UTC

[jira] [Commented] (DERBY-7015) DatabaseMetaData.getTables gives exception when called from two threads and the statement is stale

    [ https://issues.apache.org/jira/browse/DERBY-7015?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17013859#comment-17013859 ] 

Richard N. Hillegas commented on DERBY-7015:
--------------------------------------------

The DatabaseMetaData methods run queries against the SYS.SYS* tables. That is, they do not rely on the DataDictionary's in-memory metadata cache. I am, however, suprised that a DatabaseMetaData query would deadlock against another instance of itself. Might there be another thread which issues DDL at the same time?

> DatabaseMetaData.getTables gives exception when called from two threads and the statement is stale
> --------------------------------------------------------------------------------------------------
>
>                 Key: DERBY-7015
>                 URL: https://issues.apache.org/jira/browse/DERBY-7015
>             Project: Derby
>          Issue Type: Bug
>          Components: JDBC
>    Affects Versions: 10.14.2.0
>         Environment: Linux amd64
>            Reporter: Alex
>            Priority: Minor
>         Attachments: DerbyGetTablesDeadlockTest.java, exception-reported.txt, threads-during-hang.txt
>
>
> In certain circumstances, when two threads both call DatabaseMetaData.getTables at the same time, one fails with the exception "A lock could not be obtained within the time requested".
> This seems to be when the statement has been executed 100 times (I think as per derby.language.stalePlanCheckInterval) and the number of rows returned by the query is different compared to the first time getTables was called.
> I attach a test case which reproduces the problem on my workstation most times I execute it.
> Output from java org.apache.derby.tools.sysinfo:
> {noformat}
> ------------------ Java Information ------------------
> Java Version:    1.8.0_66
> Java Vendor:     Oracle Corporation
> Java home:       /home/myuser/bin/local/jdk1.8.0_66/jre
> Java classpath:  /home/myuser/workspace/DerbyDemo/bin:/home/myuser/workspace/DerbyDemo/lib/derby.jar:/home/myuser/workspace/DerbyDemo/lib/junit-4.11.jar:/home/myuser/workspace/DerbyDemo/lib/hamcrest-core-1.3.jar
> OS name:         Linux
> OS architecture: amd64
> OS version:      4.4.0-134-generic
> Java user name:  myuser
> Java user home:  /home/myuser
> Java user dir:   /home/myuser/workspace/DerbyDemo
> java.specification.name: Java Platform API Specification
> java.specification.version: 1.8
> java.runtime.version: 1.8.0_66-b17
> --------- Derby Information --------
> [/home/myuser/workspace/DerbyDemo/lib/derby.jar] 10.14.2.0 - (1828579)
> ------------------------------------------------------
> ----------------- Locale Information -----------------
> ------------------------------------------------------
> ------------------------------------------------------{noformat}
> Also attached is the exception that it produces, and also a jstack of the two threads when everything is hung but before the exception is thrown.
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)