Question on resolved issue DERBY-2861...are the lock timeouts expected

[Jeff Clary <jc...@actuate.com>]

Folks,

 

I filed a JIRA (DERBY-2861) last year about a NPE occurring when a large
number of threads created/dropped views simultaneously.  A fix for that
issue is checked in for version 10.5.0.0.  (Thanks to Dag Wanvik.)

 

However, now when I run my test with 100 threads I am still seeing an
"ERROR 40XL1: A lock could not be obtained within the time requested."
See the stack trace below.  In the comments to DERBY-2861, I see that
others sometimes get a similar result.

 

Anyone care to speculate on whether I should expect this behavior?  Is
it just the case that so many threads overwhelm Derby, and it is unable
to keep up...causing some statements to time out and get canceled?  Or
might there be some bona fide deadlock condition still lurking?

 

I have played around a little bit, using fewer threads and introducing
delays, but the only way so far I have been able to duplicate this
behavior is with lots of threads...75 to 100.

 

Thanks,

Jeff Clary

 

 

 

 

java.sql.SQLException: A lock could not be obtained within the time
requested

  at
org.apache.derby.impl.jdbc.SQLExceptionFactory.getSQLException(SQLExcept
ionFactory.java:45)

  at
org.apache.derby.impl.jdbc.Util.generateCsSQLException(Util.java:201)

  at
org.apache.derby.impl.jdbc.TransactionResourceImpl.wrapInSQLException(Tr
ansactionResourceImpl.java:391)

  at
org.apache.derby.impl.jdbc.TransactionResourceImpl.handleException(Trans
actionResourceImpl.java:346)

  at
org.apache.derby.impl.jdbc.EmbedConnection.handleException(EmbedConnecti
on.java:2135)

  at
org.apache.derby.impl.jdbc.ConnectionChild.handleException(ConnectionChi
ld.java:81)

  at
org.apache.derby.impl.jdbc.EmbedStatement.execute(EmbedStatement.java:61
4)

  at
org.apache.derby.impl.jdbc.EmbedStatement.execute(EmbedStatement.java:55
5)

  at
TestEmbeddedMultiThreading.executeStatement(TestEmbeddedMultiThreading.j
ava:129)

  at
TestEmbeddedMultiThreading.access$100(TestEmbeddedMultiThreading.java:29
)

  at
TestEmbeddedMultiThreading$ViewCreatorDropper.run(TestEmbeddedMultiThrea
ding.java:194)

  at java.lang.Thread.run(Thread.java:595)

Caused by: ERROR 40XL1: A lock could not be obtained within the time
requested

  at
org.apache.derby.iapi.error.StandardException.newException(StandardExcep
tion.java:276)

  at
org.apache.derby.impl.services.locks.ConcurrentLockSet.lockObject(Concur
rentLockSet.java:602)

  at
org.apache.derby.impl.services.locks.AbstractPool.lockObject(AbstractPoo
l.java:119)

  at
org.apache.derby.impl.store.raw.xact.RowLocking2.lockRecordForRead(RowLo
cking2.java:165)

  at
org.apache.derby.impl.store.access.btree.index.B2IRowLocking3._lockScan(
B2IRowLocking3.java:127)

  at
org.apache.derby.impl.store.access.btree.index.B2IRowLocking3.lockScan(B
2IRowLocking3.java:739)

  at
org.apache.derby.impl.store.access.btree.index.B2IRowLocking3._lockScanR
ow(B2IRowLocking3.java:662)

  at
org.apache.derby.impl.store.access.btree.index.B2IRowLockingRR.lockScanR
ow(B2IRowLockingRR.java:112)

  at
org.apache.derby.impl.store.access.btree.BTreeScan.positionAtStartForFor
wardScan(BTreeScan.java:436)

  at
org.apache.derby.impl.store.access.btree.BTreeForwardScan.positionAtStar
tPosition(BTreeForwardScan.java:71)

  at
org.apache.derby.impl.store.access.btree.BTreeForwardScan.fetchRows(BTre
eForwardScan.java:123)

  at
org.apache.derby.impl.store.access.btree.BTreeScan.next(BTreeScan.java:1
756)

  at
org.apache.derby.impl.sql.catalog.DataDictionaryImpl.getDescriptorViaInd
exMinion(DataDictionaryImpl.java:7995)

  at
org.apache.derby.impl.sql.catalog.DataDictionaryImpl.getDescriptorViaInd
ex(DataDictionaryImpl.java:7896)

  at
org.apache.derby.impl.sql.catalog.DataDictionaryImpl.getColumnDescriptor
sScan(DataDictionaryImpl.java:2369)

  at
org.apache.derby.impl.sql.catalog.DataDictionaryImpl.getColumnDescriptor
sScan(DataDictionaryImpl.java:2333)

  at
org.apache.derby.impl.sql.catalog.DataDictionaryImpl.finishTableDescript
or(DataDictionaryImpl.java:2032)

  at
org.apache.derby.impl.sql.catalog.DataDictionaryImpl.getTableDescriptorI
ndex1Scan(DataDictionaryImpl.java:1901)

  at
org.apache.derby.impl.sql.catalog.DataDictionaryImpl.getTableDescriptor(
DataDictionaryImpl.java:1859)

  at
org.apache.derby.impl.sql.compile.DropViewNode.bindStatement(DropViewNod
e.java:79)

  at
org.apache.derby.impl.sql.GenericStatement.prepMinion(GenericStatement.j
ava:314)

  at
org.apache.derby.impl.sql.GenericStatement.prepare(GenericStatement.java
:88)

  at
org.apache.derby.impl.sql.conn.GenericLanguageConnectionContext.prepareI
nternalStatement(GenericLanguageConnectionContext.java:794)

  at
org.apache.derby.impl.jdbc.EmbedStatement.execute(EmbedStatement.java:60
6)

  ... 5 more

Re: Question on resolved issue DERBY-2861...are the lock timeouts expected

["Dag H. Wanvik" <Da...@Sun.COM>]

Jeff Clary <jc...@actuate.com> writes:

> However, now when I run my test with 100 threads I am still seeing an
> "ERROR 40XL1: A lock could not be obtained within the time requested."
> See the stack trace below.  In the comments to DERBY-2861, I see that
> others sometimes get a similar result.

You are using the same test as attached to the issue DERBY-2861?  It
may not be an error, if many threads are competing for locks to
dictionary to compile some could end up waiting too long; what is your
lock waitTimeout? You could try to tweak it to see if it changes
things.

http://db.apache.org/derby/docs/10.4/tuning/rtunproper46141.html#rtunproper46141

Dag