Svata Dedic <[EMAIL PROTECTED]> writes: > Knut Anders Hatlen wrote: >> Svata Dedic <[EMAIL PROTECTED]> 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
