Svata Dedic <[EMAIL PROTECTED]> writes: > Hello, > > I am new to this list - so please accept my apologies if I ask something > well known (I did a keyword google/list search with no reasonable results) > > I have the following issue: my code changes DB structure (create a > column), then immediately after setting autocommit back to true, the > code rescans the DB metadata > DatabaseMetaData.getColumns(catalog, schemaName, tableName, null); > [...] > I am sometimes getting a deadlock with these operations: > I am quite positive that, at the time, no other threads access the > database (and there are no pending DB operations on the threaddump while > waiting on the lock). > > I've seen the deadlock occur during several get-metadata operations > (getImportedKeys, ...), each time waiting on the SYSSTATEMENTS > apparently because of internally constructed PreparedStatement. > > 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.
Do the deadlock exceptions propagate out to your code, or do you only see them in derby.log? I know that there is some code in that area that may cause internal deadlocks or timeouts, but it successfully recovers from the errors and doesn't expose the exceptions to the users. When that happens, you may experience that your application hangs for a while 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 -- Knut Anders
