db-derby-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Svata Dedic <ga...@volny.cz>
Subject Deadlock when getting DB metadata
Date Wed, 16 Apr 2008 20:15:24 GMT
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:

2008-04-16 19:50:47.833 GMT Thread[Default RequestProcessor,1,system]
(XID = 569844), (SESSIONID = 2), (DATABASE =
/..../a3/.config/localdb/db), (DRDAID = null), Cleanup action starting
2008-04-16 19:50:47.833 GMT Thread[Default RequestProcessor,1,system]
(XID = 569844), (SESSIONID = 2), (DATABASE =
/..../IJCProjects/a3/.config/localdb/db), (DRDAID = null), Failed
Statement is: EXECUTE STATEMENT SYS."getColumns"
ERROR 40XL2: A lock could not be obtained within the time requested.
The lockTable dump is:
2008-04-16 19:50:47.796 GMT
XID       |TYPE         |MODE|LOCKCOUNT|LOCKNAME
                                                |STATE|TABLETYPE /
LOCKOBJ                   |INDEXNAME / CONTAINER_ID / (MODE for LATCH
only)  |TABLENAME / CONGLOM_ID                |
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
*** The following row is the victim ***
569852    |ROW          |X   |0        |(44,7)
                                                |WAIT |S
                     |NULL
|SYSSTATEMENTS                         |
*** The above row is the victim ***

the stacktrace of the operation causing the deadlock is

        at
org.apache.derby.iapi.error.StandardException.newException(Unknown Source)
        at
org.apache.derby.impl.services.locks.Timeout.createException(Unknown Source)
        at
org.apache.derby.impl.services.locks.Timeout.buildException(Unknown Source)
        at
org.apache.derby.impl.services.locks.ConcurrentLockSet.lockObject(Unknown
Source)
        at
org.apache.derby.impl.services.locks.AbstractPool.lockObject(Unknown Source)
        at
org.apache.derby.impl.services.locks.ConcurrentPool.lockObject(Unknown
Source)
        at
org.apache.derby.impl.store.raw.xact.RowLocking3.lockRecordForWrite(Unknown
Source)
        at
org.apache.derby.impl.store.access.heap.HeapController.lockRow(Unknown
Source)
        at
org.apache.derby.impl.store.access.heap.HeapController.lockRow(Unknown
Source)
        at
org.apache.derby.impl.store.access.btree.index.B2IRowLocking3.lockRowOnPage(Unknown
Source)
        at
org.apache.derby.impl.store.access.btree.index.B2IRowLocking3._lockScanRow(Unknown
Source)
        at
org.apache.derby.impl.store.access.btree.index.B2IRowLockingRR.lockScanRow(Unknown
Source)
        at
org.apache.derby.impl.store.access.btree.BTreeForwardScan.fetchRows(Unknown
Source)
        at
org.apache.derby.impl.store.access.btree.BTreeScan.fetchNext(Unknown Source)
        at
org.apache.derby.impl.sql.catalog.TabInfoImpl.updateRow(Unknown Source)
        at
org.apache.derby.impl.sql.catalog.TabInfoImpl.updateRow(Unknown Source)
        at
org.apache.derby.impl.sql.catalog.DataDictionaryImpl.updateSPS(Unknown
Source)
        at
org.apache.derby.iapi.sql.dictionary.SPSDescriptor.updateSYSSTATEMENTS(Unknown
Source)
        at
org.apache.derby.iapi.sql.dictionary.SPSDescriptor.getPreparedStatement(Unknown
Source)
        at
org.apache.derby.iapi.sql.dictionary.SPSDescriptor.getPreparedStatement(Unknown
Source)
        at
org.apache.derby.impl.sql.compile.ExecSPSNode.generate(Unknown Source)
        at org.apache.derby.impl.sql.GenericStatement.prepMinion(Unknown
Source)
        at org.apache.derby.impl.sql.GenericStatement.prepare(Unknown
Source)
        at
org.apache.derby.impl.sql.GenericPreparedStatement.rePrepare(Unknown Source)
        at
org.apache.derby.impl.sql.GenericPreparedStatement.execute(Unknown Source)
        at
org.apache.derby.impl.jdbc.EmbedStatement.executeStatement(Unknown Source)
        at
org.apache.derby.impl.jdbc.EmbedPreparedStatement.executeStatement(Unknown
Source)
        at
org.apache.derby.impl.jdbc.EmbedPreparedStatement.executeQuery(Unknown
Source)
        at
org.apache.derby.impl.jdbc.EmbedDatabaseMetaData.doGetCols(Unknown Source)
        at
org.apache.derby.impl.jdbc.EmbedDatabaseMetaData.getColumns(Unknown Source)


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.

Thanks,
-Svata

Mime
View raw message