You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-user@db.apache.org by Jeremiah Jahn <je...@goodinassociates.com> on 2005/02/08 22:37:38 UTC
lock timeout problems
I have autocommit set to true and one process accessing the system at a
time. anyone know of a reason that a delete * from a table would give me
this message?
ERROR 40XL1: A lock could not be obtained within the time requested
at org.apache.derby.iapi.error.StandardException.newException(StandardException.java)
at org.apache.derby.impl.services.locks.LockSet.lockObject(LockSet.java)
at org.apache.derby.impl.services.locks.SinglePool.lockAnObject(SinglePool.java)
at org.apache.derby.impl.services.locks.SinglePool.lockObject(SinglePool.java)
at org.apache.derby.impl.store.raw.xact.RowLocking3.lockRecordForWrite(RowLocking3.java)
at org.apache.derby.impl.store.access.heap.HeapController.lockRow(HeapController.java)
at org.apache.derby.impl.store.access.heap.HeapController.lockRow(HeapController.java)
at org.apache.derby.impl.store.access.btree.index.B2IRowLocking3.lockRowOnPage(B2IRowLocking3.java)
at org.apache.derby.impl.store.access.btree.index.B2IRowLocking3._lockScanRow(B2IRowLocking3.java)
at org.apache.derby.impl.store.access.btree.index.B2IRowLockingRR.lockScanRow(B2IRowLockingRR.java)
at org.apache.derby.impl.store.access.btree.BTreeForwardScan.fetchRows(BTreeForwardScan.java)
at org.apache.derby.impl.store.access.btree.BTreeScan.next(BTreeScan.java)
at org.apache.derby.impl.sql.execute.IndexChanger.doDelete(IndexChanger.java)
at org.apache.derby.impl.sql.execute.IndexChanger.delete(IndexChanger.java)
at org.apache.derby.impl.sql.execute.IndexSetChanger.delete(IndexSetChanger.java)
at org.apache.derby.impl.sql.execute.RowChangerImpl.deleteRow(RowChangerImpl.java)
at org.apache.derby.impl.sql.execute.DeleteResultSet.collectAffectedRows(DeleteResultSet.java)
at org.apache.derby.impl.sql.execute.DeleteResultSet.open(DeleteResultSet.java)
at org.apache.derby.impl.sql.GenericPreparedStatement.execute(GenericPreparedStatement.java)
at org.apache.derby.impl.jdbc.EmbedStatement.executeStatement(EmbedStatement.java)
at org.apache.derby.impl.jdbc.EmbedStatement.execute(EmbedStatement.java)
at org.apache.derby.impl.jdbc.EmbedStatement.executeUpdate(EmbedStatement.java)
at com.goodinassociates.evidencetracking.functionaltests.DatabaseTestHelper.cleanTable(DatabaseTestHelper.java:598)
at com.goodinassociates.evidencetracking.functionaltests.DatabaseTestHelper.cleanOrganizationTable(DatabaseTestHelper.java:135)
at com.goodinassociates.evidencetracking.functionaltests.DatabaseTestHelper.prepareOrganizationTable(DatabaseTestHelper.java:112)
at com.goodinassociates.evidencetracking.organization.OrganizationTest.setUp(OrganizationTest.java:35)
at junit.framework.TestCase.runBare(TestCase.java:125)
at junit.framework.TestResult$1.protect(TestResult.java:106)
at junit.framework.TestResult.runProtected(TestResult.java:124)
at junit.framework.TestResult.run(TestResult.java:109)
at junit.framework.TestCase.run(TestCase.java:118)
at junit.framework.TestSuite.runTest(TestSuite.java:208)
at junit.framework.TestSuite.run(TestSuite.java:203)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:421)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:305)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:186)
The men sat sipping their tea in silence. After a while the klutz said,
"Life is like a bowl of sour cream." "Like a bowl of sour cream?" asked
the other. "Why?" "How should I know? What am I, a philosopher?"
Re: lock timeout problems
Posted by Jeremiah Jahn <je...@goodinassociates.com>.
That helped a lot, thanx.
I was leaving resultSets open in places.
On Tue, 2005-02-08 at 16:22 -0800, Suresh Thalamati wrote:
> It is strange that you are getting lock time out error with a single
> thread. First thing I would
> do is to identify what is holding the lock for this thread to get lock
> time out. One way to
> do that is to set the following properties in derby.properties or with
> -D option on JVM start.
>
> derby.locks.monitor=true
> derby.locks.deadlockTrace=true
>
> When you set the above properties lock table will be dumped to
> derby.log when timeout occurs.
> More info is available at:
> http://incubator.apache.org/derby/manuals/admin/hubprnt56.html#Lock+Monitoring
>
> Lock table might not have the SQL statement which is holding the lock.
> Following property might help in locating the statement:
> derby.language.logStatementText
> <http://incubator.apache.org/derby/manuals/tuning/perf77.html#derby.language.logStatementText>
>
> http://incubator.apache.org/derby/manuals/tuning/perf77.html
>
> when logStatementText property is set all the statement executed on the
> system will be written to the derby.log.
> Statement information also includes the transaction id on which the
> statement being executed.
>
> Using the transaction ID that is holding the lock in the lock table dump
> if you do a reverse search
> for the transaction id in the derby.log , it is possible to narrow down
> the statements that might be
> holding the locks.
>
>
> -suresh
>
>
>
> Jeremiah Jahn wrote:
>
> >I have autocommit set to true and one process accessing the system at a
> >time. anyone know of a reason that a delete * from a table would give me
> >this message?
> >
> >ERROR 40XL1: A lock could not be obtained within the time requested
> > at org.apache.derby.iapi.error.StandardException.newException(StandardException.java)
> > at org.apache.derby.impl.services.locks.LockSet.lockObject(LockSet.java)
> > at org.apache.derby.impl.services.locks.SinglePool.lockAnObject(SinglePool.java)
> > at org.apache.derby.impl.services.locks.SinglePool.lockObject(SinglePool.java)
> > at org.apache.derby.impl.store.raw.xact.RowLocking3.lockRecordForWrite(RowLocking3.java)
> > at org.apache.derby.impl.store.access.heap.HeapController.lockRow(HeapController.java)
> > at org.apache.derby.impl.store.access.heap.HeapController.lockRow(HeapController.java)
> > at org.apache.derby.impl.store.access.btree.index.B2IRowLocking3.lockRowOnPage(B2IRowLocking3.java)
> > at org.apache.derby.impl.store.access.btree.index.B2IRowLocking3._lockScanRow(B2IRowLocking3.java)
> > at org.apache.derby.impl.store.access.btree.index.B2IRowLockingRR.lockScanRow(B2IRowLockingRR.java)
> > at org.apache.derby.impl.store.access.btree.BTreeForwardScan.fetchRows(BTreeForwardScan.java)
> > at org.apache.derby.impl.store.access.btree.BTreeScan.next(BTreeScan.java)
> > at org.apache.derby.impl.sql.execute.IndexChanger.doDelete(IndexChanger.java)
> > at org.apache.derby.impl.sql.execute.IndexChanger.delete(IndexChanger.java)
> > at org.apache.derby.impl.sql.execute.IndexSetChanger.delete(IndexSetChanger.java)
> > at org.apache.derby.impl.sql.execute.RowChangerImpl.deleteRow(RowChangerImpl.java)
> > at org.apache.derby.impl.sql.execute.DeleteResultSet.collectAffectedRows(DeleteResultSet.java)
> > at org.apache.derby.impl.sql.execute.DeleteResultSet.open(DeleteResultSet.java)
> > at org.apache.derby.impl.sql.GenericPreparedStatement.execute(GenericPreparedStatement.java)
> > at org.apache.derby.impl.jdbc.EmbedStatement.executeStatement(EmbedStatement.java)
> > at org.apache.derby.impl.jdbc.EmbedStatement.execute(EmbedStatement.java)
> > at org.apache.derby.impl.jdbc.EmbedStatement.executeUpdate(EmbedStatement.java)
> > at com.goodinassociates.evidencetracking.functionaltests.DatabaseTestHelper.cleanTable(DatabaseTestHelper.java:598)
> > at com.goodinassociates.evidencetracking.functionaltests.DatabaseTestHelper.cleanOrganizationTable(DatabaseTestHelper.java:135)
> > at com.goodinassociates.evidencetracking.functionaltests.DatabaseTestHelper.prepareOrganizationTable(DatabaseTestHelper.java:112)
> > at com.goodinassociates.evidencetracking.organization.OrganizationTest.setUp(OrganizationTest.java:35)
> > at junit.framework.TestCase.runBare(TestCase.java:125)
> > at junit.framework.TestResult$1.protect(TestResult.java:106)
> > at junit.framework.TestResult.runProtected(TestResult.java:124)
> > at junit.framework.TestResult.run(TestResult.java:109)
> > at junit.framework.TestCase.run(TestCase.java:118)
> > at junit.framework.TestSuite.runTest(TestSuite.java:208)
> > at junit.framework.TestSuite.run(TestSuite.java:203)
> > at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:421)
> > at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:305)
> > at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:186)
> >
> >
> >The men sat sipping their tea in silence. After a while the klutz said,
> >"Life is like a bowl of sour cream." "Like a bowl of sour cream?" asked
> >the other. "Why?" "How should I know? What am I, a philosopher?"
> >
> >
OK, so you're a Ph.D. Just don't touch anything.
Re: lock timeout problems
Posted by Suresh Thalamati <su...@gmail.com>.
It is strange that you are getting lock time out error with a single
thread. First thing I would
do is to identify what is holding the lock for this thread to get lock
time out. One way to
do that is to set the following properties in derby.properties or with
-D option on JVM start.
derby.locks.monitor=true
derby.locks.deadlockTrace=true
When you set the above properties lock table will be dumped to
derby.log when timeout occurs.
More info is available at:
http://incubator.apache.org/derby/manuals/admin/hubprnt56.html#Lock+Monitoring
Lock table might not have the SQL statement which is holding the lock.
Following property might help in locating the statement:
derby.language.logStatementText
<http://incubator.apache.org/derby/manuals/tuning/perf77.html#derby.language.logStatementText>
http://incubator.apache.org/derby/manuals/tuning/perf77.html
when logStatementText property is set all the statement executed on the
system will be written to the derby.log.
Statement information also includes the transaction id on which the
statement being executed.
Using the transaction ID that is holding the lock in the lock table dump
if you do a reverse search
for the transaction id in the derby.log , it is possible to narrow down
the statements that might be
holding the locks.
-suresh
Jeremiah Jahn wrote:
>I have autocommit set to true and one process accessing the system at a
>time. anyone know of a reason that a delete * from a table would give me
>this message?
>
>ERROR 40XL1: A lock could not be obtained within the time requested
> at org.apache.derby.iapi.error.StandardException.newException(StandardException.java)
> at org.apache.derby.impl.services.locks.LockSet.lockObject(LockSet.java)
> at org.apache.derby.impl.services.locks.SinglePool.lockAnObject(SinglePool.java)
> at org.apache.derby.impl.services.locks.SinglePool.lockObject(SinglePool.java)
> at org.apache.derby.impl.store.raw.xact.RowLocking3.lockRecordForWrite(RowLocking3.java)
> at org.apache.derby.impl.store.access.heap.HeapController.lockRow(HeapController.java)
> at org.apache.derby.impl.store.access.heap.HeapController.lockRow(HeapController.java)
> at org.apache.derby.impl.store.access.btree.index.B2IRowLocking3.lockRowOnPage(B2IRowLocking3.java)
> at org.apache.derby.impl.store.access.btree.index.B2IRowLocking3._lockScanRow(B2IRowLocking3.java)
> at org.apache.derby.impl.store.access.btree.index.B2IRowLockingRR.lockScanRow(B2IRowLockingRR.java)
> at org.apache.derby.impl.store.access.btree.BTreeForwardScan.fetchRows(BTreeForwardScan.java)
> at org.apache.derby.impl.store.access.btree.BTreeScan.next(BTreeScan.java)
> at org.apache.derby.impl.sql.execute.IndexChanger.doDelete(IndexChanger.java)
> at org.apache.derby.impl.sql.execute.IndexChanger.delete(IndexChanger.java)
> at org.apache.derby.impl.sql.execute.IndexSetChanger.delete(IndexSetChanger.java)
> at org.apache.derby.impl.sql.execute.RowChangerImpl.deleteRow(RowChangerImpl.java)
> at org.apache.derby.impl.sql.execute.DeleteResultSet.collectAffectedRows(DeleteResultSet.java)
> at org.apache.derby.impl.sql.execute.DeleteResultSet.open(DeleteResultSet.java)
> at org.apache.derby.impl.sql.GenericPreparedStatement.execute(GenericPreparedStatement.java)
> at org.apache.derby.impl.jdbc.EmbedStatement.executeStatement(EmbedStatement.java)
> at org.apache.derby.impl.jdbc.EmbedStatement.execute(EmbedStatement.java)
> at org.apache.derby.impl.jdbc.EmbedStatement.executeUpdate(EmbedStatement.java)
> at com.goodinassociates.evidencetracking.functionaltests.DatabaseTestHelper.cleanTable(DatabaseTestHelper.java:598)
> at com.goodinassociates.evidencetracking.functionaltests.DatabaseTestHelper.cleanOrganizationTable(DatabaseTestHelper.java:135)
> at com.goodinassociates.evidencetracking.functionaltests.DatabaseTestHelper.prepareOrganizationTable(DatabaseTestHelper.java:112)
> at com.goodinassociates.evidencetracking.organization.OrganizationTest.setUp(OrganizationTest.java:35)
> at junit.framework.TestCase.runBare(TestCase.java:125)
> at junit.framework.TestResult$1.protect(TestResult.java:106)
> at junit.framework.TestResult.runProtected(TestResult.java:124)
> at junit.framework.TestResult.run(TestResult.java:109)
> at junit.framework.TestCase.run(TestCase.java:118)
> at junit.framework.TestSuite.runTest(TestSuite.java:208)
> at junit.framework.TestSuite.run(TestSuite.java:203)
> at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:421)
> at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:305)
> at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:186)
>
>
>The men sat sipping their tea in silence. After a while the klutz said,
>"Life is like a bowl of sour cream." "Like a bowl of sour cream?" asked
>the other. "Why?" "How should I know? What am I, a philosopher?"
>
>