[
https://issues.apache.org/jira/browse/DERBY-5667?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13898566#comment-13898566
]
Mike Matrigali commented on DERBY-5667:
---------------------------------------
I looked closely at the first failure in your recent posting, a failure in
testSerializable, with updateBtreeSetLocks. This test is expecting a query
plan to use the index. The difference is rather than 3 X row locks, we end up
with 2 X row locks and a U lock.
The query is:
/* ------------------------------------------------------------
* Test updates an exact match on a with base row qualification
* necessary.
*
* At this point the table should look like:
* 1, 10, 'one'
* 3, 300, 'three'
* 5, 50, 'five'
* 7, 70, 'seven'
* ------------------------------------------------------------
*/
s.executeUpdate(
"update a set b = 30 where a = 3 and b = 300");
There is a index on a, and query needs to go to base table to read and write b.
I think the expected locks are:
look up a=3 in index (IX table on a, X lock on row a=3)
find base row and get value b (X lock on row a=3, b=300 in base table)
separate step to update the value in base table (IX table on a, X lock on row
a=3, b=300)
I believe we actually in-line ask for a U row lock first at some point and then
escalate
it to X when we have gotten it and know we are going to do the update. I don't
know
why a U lock would be left around in any case. It would not cause any problem
because the xact already has X lock until end transaction so the U lock becomes
meaningless.
The lock count is an internal implementation detail and probably should not have
been exposed, but doing that would have been more work than just dumping the
lock table state. And originally the tool really was more for debugging the
lock
manager than providing something for users.
I looked closely and it looks like the code handles committed deletes with
proper wait for post commit.
So, given you are seeing intermittent issues, I started wondering if it could
be related to the other background timing issue with tests - the automatic
statistics gatherer. This test has very few rows and in this test case I
think all the rows fit on one page of index and one page of a data page. I
could see the optmizer picking
a different plan with a change of statistics. I sugest turning off the
statistics gatherer for all locking tests like these
that expect to own exactly how the query will be executed.
> testReadCommitted(org.apache.derbyTesting.functionTests.tests.store.UpdateLocksTest)junit.framework.AssertionFailedError:
> Missing rows in ResultSet
> ---------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-5667
> URL: https://issues.apache.org/jira/browse/DERBY-5667
> Project: Derby
> Issue Type: Bug
> Components: Test
> Affects Versions: 10.8.3.0
> Reporter: Mike Matrigali
> Assignee: Myrna van Lunteren
> Fix For: 10.8.3.0, 10.9.1.0
>
> Attachments: DERBY-5667.diff, DERBY-5667_2.diff, DERBY-5667_3.diff,
> DERBY-5667_3_109.diff, DERBY-5667_3b.diff
>
>
> one failure and 2 errors which I would guess are because of the failure.
> Failed against 10.8 branch, ibm15, windows, build 1302046
> There were 2 errors:
> 1)
> testSerializable(org.apache.derbyTesting.functionTests.tests.store.UpdateLocksTest)java.sql.SQLException:
> Table/View 'A' already exists in Schema 'APP'.
> at
> org.apache.derby.impl.jdbc.SQLExceptionFactory.getSQLException(Unknown Source)
> at org.apache.derby.impl.jdbc.Util.generateCsSQLException(Unknown
> Source)
> at
> org.apache.derby.impl.jdbc.TransactionResourceImpl.wrapInSQLException(Unknown
> Source)
> at
> org.apache.derby.impl.jdbc.TransactionResourceImpl.handleException(Unknown
> Source)
> at org.apache.derby.impl.jdbc.EmbedConnection.handleException(Unknown
> Source)
> at org.apache.derby.impl.jdbc.ConnectionChild.handleException(Unknown
> Source)
> at org.apache.derby.impl.jdbc.EmbedStatement.executeStatement(Unknown
> Source)
> at org.apache.derby.impl.jdbc.EmbedStatement.execute(Unknown Source)
> at org.apache.derby.impl.jdbc.EmbedStatement.executeUpdate(Unknown
> Source)
> at
> org.apache.derbyTesting.functionTests.tests.store.UpdateLocksTest.doRunTests(UpdateLocksTest.java:185)
> at
> org.apache.derbyTesting.functionTests.tests.store.UpdateLocksTest.testSerializable(UpdateLocksTest.java:154)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:79)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at
> org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:113)
> at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
> at junit.extensions.TestSetup$1.protect(TestSetup.java:21)
> at junit.extensions.TestSetup.run(TestSetup.java:25)
> at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
> at junit.extensions.TestSetup$1.protect(TestSetup.java:21)
> at junit.extensions.TestSetup.run(TestSetup.java:25)
> at
> org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57)
> Caused by: ERROR X0Y32: Table/View 'A' already exists in Schema 'APP'.
> at org.apache.derby.iapi.error.StandardException.newException(Unknown
> Source)
> at
> org.apache.derby.impl.sql.catalog.DataDictionaryImpl.duplicateDescriptorException(Unknown
> Source)
> at
> org.apache.derby.impl.sql.catalog.DataDictionaryImpl.addDescriptor(Unknown
> Source)
> at
> org.apache.derby.impl.sql.execute.CreateTableConstantAction.executeConstantAction(Unknown
> Source)
> at org.apache.derby.impl.sql.execute.MiscResultSet.open(Unknown Source)
> at
> org.apache.derby.impl.sql.GenericPreparedStatement.executeStmt(Unknown Source)
> at org.apache.derby.impl.sql.GenericPreparedStatement.execute(Unknown
> Source)
> ... 36 more
> 2)
> testReadUncommitted(org.apache.derbyTesting.functionTests.tests.store.UpdateLocksTest)java.sql.SQLException:
> Table/View 'A' already exists in Schema 'APP'.
> at
> org.apache.derby.impl.jdbc.SQLExceptionFactory.getSQLException(Unknown Source)
> at org.apache.derby.impl.jdbc.Util.generateCsSQLException(Unknown
> Source)
> at
> org.apache.derby.impl.jdbc.TransactionResourceImpl.wrapInSQLException(Unknown
> Source)
> at
> org.apache.derby.impl.jdbc.TransactionResourceImpl.handleException(Unknown
> Source)
> at org.apache.derby.impl.jdbc.EmbedConnection.handleException(Unknown
> Source)
> at org.apache.derby.impl.jdbc.ConnectionChild.handleException(Unknown
> Source)
> at org.apache.derby.impl.jdbc.EmbedStatement.executeStatement(Unknown
> Source)
> at org.apache.derby.impl.jdbc.EmbedStatement.execute(Unknown Source)
> at org.apache.derby.impl.jdbc.EmbedStatement.executeUpdate(Unknown
> Source)
> at
> org.apache.derbyTesting.functionTests.tests.store.UpdateLocksTest.doRunTests(UpdateLocksTest.java:185)
> at
> org.apache.derbyTesting.functionTests.tests.store.UpdateLocksTest.testReadUncommitted(UpdateLocksTest.java:158)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:79)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at
> org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:113)
> at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
> at junit.extensions.TestSetup$1.protect(TestSetup.java:21)
> at junit.extensions.TestSetup.run(TestSetup.java:25)
> at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
> at junit.extensions.TestSetup$1.protect(TestSetup.java:21)
> at junit.extensions.TestSetup.run(TestSetup.java:25)
> at
> org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57)
> Caused by: ERROR X0Y32: Table/View 'A' already exists in Schema 'APP'.
> at org.apache.derby.iapi.error.StandardException.newException(Unknown
> Source)
> at
> org.apache.derby.impl.sql.catalog.DataDictionaryImpl.duplicateDescriptorException(Unknown
> Source)
> at
> org.apache.derby.impl.sql.catalog.DataDictionaryImpl.addDescriptor(Unknown
> Source)
> at
> org.apache.derby.impl.sql.execute.CreateTableConstantAction.executeConstantAction(Unknown
> Source)
> at org.apache.derby.impl.sql.execute.MiscResultSet.open(Unknown Source)
> at
> org.apache.derby.impl.sql.GenericPreparedStatement.executeStmt(Unknown Source)
> at org.apache.derby.impl.sql.GenericPreparedStatement.execute(Unknown
> Source)
> ... 36 more
> There were 2 failures:
> 1)
> testReadCommitted(org.apache.derbyTesting.functionTests.tests.store.UpdateLocksTest)junit.framework.AssertionFailedError:
> Missing rows in ResultSet
> at
> org.apache.derbyTesting.junit.JDBC.assertUnorderedResultSet(JDBC.java:1349)
> at
> org.apache.derbyTesting.junit.JDBC.assertUnorderedResultSet(JDBC.java:1285)
> at
> org.apache.derbyTesting.functionTests.tests.store.UpdateLocksTest.updateBtreeSetLocks(UpdateLocksTest.java:6764)
> at
> org.apache.derbyTesting.functionTests.tests.store.UpdateLocksTest.doRunTests(UpdateLocksTest.java:387)
> at
> org.apache.derbyTesting.functionTests.tests.store.UpdateLocksTest.testReadCommitted(UpdateLocksTest.java:150)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:79)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at
> org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:113)
> at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
> at junit.extensions.TestSetup$1.protect(TestSetup.java:21)
> at junit.extensions.TestSetup.run(TestSetup.java:25)
> at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
> at junit.extensions.TestSetup$1.protect(TestSetup.java:21)
> at junit.extensions.TestSetup.run(TestSetup.java:25)
> at
> org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57)
> http://people.apache.org/~myrnavl/derby_test_results/v10_8/windows/testlog/ibm15/1302046-suites.All_diff.txt
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
