[
https://issues.apache.org/jira/browse/DERBY-5073?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13007722#comment-13007722
]
Karl Wright commented on DERBY-5073:
------------------------------------
A trunk build does the same thing on my test case. I got a thread dump when I
thought it had locked itself up. There were a whole pile of threads all
waiting for grants, and then there was this thread:
Thread-24341" daemon prio=6 tid=0x05934400 nid=0x1cd4 runnable [0x0816e000]
java.lang.Thread.State: RUNNABLE
at java.util.Hashtable.get(Hashtable.java:333)
- locked <0x29280528> (a java.util.Hashtable)
at
org.apache.derby.shared.common.sanity.SanityManager.DEBUG_ON(SanityManager.java:229)
at
org.apache.derby.impl.services.locks.AbstractPool.lockObject(AbstractPool.java:101)
at
org.apache.derby.impl.store.raw.xact.RowLocking2.lockRecordForRead(RowLocking2.java:165)
at
org.apache.derby.impl.store.access.heap.HeapController.lockRow(HeapController.java:520)
at
org.apache.derby.impl.store.access.heap.HeapController.lockRow(HeapController.java:638)
at
org.apache.derby.impl.store.access.btree.index.B2IRowLocking3.lockRowOnPage(B2IRowLocking3.java:280)
at
org.apache.derby.impl.store.access.btree.index.B2IRowLocking3._lockScanRow(B2IRowLocking3.java:599)
at
org.apache.derby.impl.store.access.btree.index.B2IRowLockingRR.lockScanRow(B2IRowLockingRR.java:105)
at
org.apache.derby.impl.store.access.btree.BTreeForwardScan.fetchRows(BTreeForwardScan.java:305)
at
org.apache.derby.impl.store.access.btree.BTreeScan.fetchNext(BTreeScan.java:1599)
at
org.apache.derby.impl.sql.execute.TableScanResultSet.getNextRowCore(TableScanResultSet.java:577)
at
org.apache.derby.impl.sql.execute.ProjectRestrictResultSet.getNextRowCore(ProjectRestrictResultSet.java:261)
at
org.apache.derby.impl.sql.execute.JoinResultSet.reopenCore(JoinResultSet.java:181)
at
org.apache.derby.impl.sql.execute.ProjectRestrictResultSet.reopenCore(ProjectRestrictResultSet.java:218)
at
org.apache.derby.impl.sql.execute.ProjectRestrictResultSet.reopenCore(ProjectRestrictResultSet.java:218)
at
org.apache.derby.impl.sql.execute.AnyResultSet.reopenCore(AnyResultSet.java:139)
at
org.apache.derby.impl.sql.execute.AnyResultSet.openCore(AnyResultSet.java:103)
at
org.apache.derby.exe.ac74f89535x012exc0d8x72ccx000000d1a4e011.g0(Unknown Source)
at
org.apache.derby.exe.ac74f89535x012exc0d8x72ccx000000d1a4e011.e1(Unknown Source)
at
org.apache.derby.impl.services.reflect.DirectCall.invoke(ReflectGeneratedClass.java:141)
at
org.apache.derby.impl.sql.execute.ProjectRestrictResultSet.getNextRowCore(ProjectRestrictResultSet.java:273)
at
org.apache.derby.impl.sql.execute.NormalizeResultSet.getNextRowCore(NormalizeResultSet.java:185)
at
org.apache.derby.impl.sql.execute.DMLWriteResultSet.getNextRowCore(DMLWriteResultSet.java:127)
at
org.apache.derby.impl.sql.execute.UpdateResultSet.collectAffectedRows(UpdateResultSet.java:440)
at
org.apache.derby.impl.sql.execute.UpdateResultSet.open(UpdateResultSet.java:264)
at
org.apache.derby.impl.sql.GenericPreparedStatement.executeStmt(GenericPreparedStatement.java:436)
at
org.apache.derby.impl.sql.GenericPreparedStatement.execute(GenericPreparedStatement.java:317)
at
org.apache.derby.impl.jdbc.EmbedStatement.executeStatement(EmbedStatement.java:1242)
- locked <0x29b139f0> (a org.apache.derby.impl.jdbc.EmbedConnection40)
at
org.apache.derby.impl.jdbc.EmbedPreparedStatement.executeStatement(EmbedPreparedStatement.java:1686)
at
org.apache.derby.impl.jdbc.EmbedPreparedStatement.executeUpdate(EmbedPreparedStatement.java:308)
at
org.apache.manifoldcf.core.database.Database.execute(Database.java:606)
at
org.apache.manifoldcf.core.database.Database$ExecuteQueryThread.run(Database.java:421)
A thread dump a couple of minutes later was identical, except for that one
thread, which now looked like this:
"Thread-24341" daemon prio=6 tid=0x05934400 nid=0x1cd4 runnable [0x0816e000]
java.lang.Thread.State: RUNNABLE
at java.lang.Object.hashCode(Native Method)
at org.apache.derby.impl.services.locks.Lock.hashCode(Lock.java:145)
at java.util.HashMap.removeEntryForKey(HashMap.java:548)
at java.util.HashMap.remove(HashMap.java:538)
at
org.apache.derby.impl.services.locks.ConcurrentLockSet.unlockReference(ConcurrentLockSet.java:799)
at
org.apache.derby.impl.services.locks.LockSpace.unlockReference(LockSpace.java:276)
- locked <0x29b14878> (a org.apache.derby.impl.services.locks.LockSpace)
at
org.apache.derby.impl.services.locks.AbstractPool.unlock(AbstractPool.java:181)
at
org.apache.derby.impl.store.raw.xact.RowLocking2.unlockRecordAfterRead(RowLocking2.java:185)
at
org.apache.derby.impl.store.access.heap.HeapController.unlockRowAfterRead(HeapController.java:668)
at
org.apache.derby.impl.store.access.btree.index.B2IRowLocking2.unlockScanRecordAfterRead(B2IRowLocking2.java:96)
at
org.apache.derby.impl.store.access.btree.BTreeForwardScan.fetchRows(BTreeForwardScan.java:221)
at
org.apache.derby.impl.store.access.btree.BTreeScan.fetchNext(BTreeScan.java:1599)
at
org.apache.derby.impl.sql.execute.TableScanResultSet.getNextRowCore(TableScanResultSet.java:577)
at
org.apache.derby.impl.sql.execute.ProjectRestrictResultSet.getNextRowCore(ProjectRestrictResultSet.java:261)
at
org.apache.derby.impl.sql.execute.JoinResultSet.reopenCore(JoinResultSet.java:181)
at
org.apache.derby.impl.sql.execute.ProjectRestrictResultSet.reopenCore(ProjectRestrictResultSet.java:218)
at
org.apache.derby.impl.sql.execute.ProjectRestrictResultSet.reopenCore(ProjectRestrictResultSet.java:218)
at
org.apache.derby.impl.sql.execute.AnyResultSet.reopenCore(AnyResultSet.java:139)
at
org.apache.derby.impl.sql.execute.AnyResultSet.openCore(AnyResultSet.java:103)
at
org.apache.derby.exe.ac74f89535x012exc0d8x72ccx000000d1a4e011.g0(Unknown Source)
at
org.apache.derby.exe.ac74f89535x012exc0d8x72ccx000000d1a4e011.e1(Unknown Source)
at
org.apache.derby.impl.services.reflect.DirectCall.invoke(ReflectGeneratedClass.java:141)
at
org.apache.derby.impl.sql.execute.ProjectRestrictResultSet.getNextRowCore(ProjectRestrictResultSet.java:273)
at
org.apache.derby.impl.sql.execute.NormalizeResultSet.getNextRowCore(NormalizeResultSet.java:185)
at
org.apache.derby.impl.sql.execute.DMLWriteResultSet.getNextRowCore(DMLWriteResultSet.java:127)
at
org.apache.derby.impl.sql.execute.UpdateResultSet.collectAffectedRows(UpdateResultSet.java:440)
at
org.apache.derby.impl.sql.execute.UpdateResultSet.open(UpdateResultSet.java:264)
at
org.apache.derby.impl.sql.GenericPreparedStatement.executeStmt(GenericPreparedStatement.java:436)
at
org.apache.derby.impl.sql.GenericPreparedStatement.execute(GenericPreparedStatement.java:317)
at
org.apache.derby.impl.jdbc.EmbedStatement.executeStatement(EmbedStatement.java:1242)
- locked <0x29b139f0> (a org.apache.derby.impl.jdbc.EmbedConnection40)
at
org.apache.derby.impl.jdbc.EmbedPreparedStatement.executeStatement(EmbedPreparedStatement.java:1686)
at
org.apache.derby.impl.jdbc.EmbedPreparedStatement.executeUpdate(EmbedPreparedStatement.java:308)
at
org.apache.manifoldcf.core.database.Database.execute(Database.java:606)
at
org.apache.manifoldcf.core.database.Database$ExecuteQueryThread.run(Database.java:421)
This *could* just be a very-long-running query, blocking lots of other stuff.
I'll have to run with the standard tricks to see what the locks wind up looking
like. Stay tuned.
> Derby deadlocks without recourse on simultaneous correlated subqueries
> ----------------------------------------------------------------------
>
> Key: DERBY-5073
> URL: https://issues.apache.org/jira/browse/DERBY-5073
> Project: Derby
> Issue Type: Bug
> Components: Services
> Affects Versions: 10.0.2.1, 10.1.2.1, 10.2.2.0, 10.3.3.0, 10.4.2.0,
> 10.5.3.0, 10.6.2.1, 10.7.1.1, 10.8.0.0
> Reporter: Karl Wright
> Attachments: Derby5073.java, derby-5073-1a.diff, derby-5073-1b.diff
>
>
> When the following two queries are run against tables that contain the
> necessary fields, using multiple threads, Derby deadlocks and none of the
> queries ever returns. Derby apparently detects no deadlock condition, either.
> SELECT t0.* FROM jobqueue t0 WHERE EXISTS(SELECT 'x' FROM carrydown t1 WHERE
> t1.parentidhash IN (?) AND t1.childidhash=t0.dochash AND t0.jobid=t1.jobid)
> AND t0.jobid=?
> SELECT t0.* FROM jobqueue t0 WHERE EXISTS(SELECT 'x' FROM carrydown t1 WHERE
> t1.parentidhash IN (?) AND t1.childidhash=t0.dochash AND t0.jobid=t1.jobid
> AND t1.newField=?) AND t0.jobid=?
> This code comes from Apache ManifoldCF, and has occurred when there are five
> or more threads trying to execute these two queries at the same time.
> Originally we found this on 10.5.3.0. It was hoped that 10.7.1.1 would fix
> the problem, but it hasn't.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
