You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-dev@db.apache.org by "Myrna van Lunteren (JIRA)" <ji...@apache.org> on 2012/04/25 04:00:06 UTC

[jira] [Issue Comment Edited] (DERBY-5667) testReadCommitted(org.apache.derbyTesting.functionTests.tests.store.UpdateLocksTest)junit.framework.AssertionFailedError: Missing rows in ResultSet

    [ https://issues.apache.org/jira/browse/DERBY-5667?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13261204#comment-13261204 ] 

Myrna van Lunteren edited comment on DERBY-5667 at 4/25/12 1:59 AM:
--------------------------------------------------------------------

You're right of course.
This was because I looked at the stack trace of the original error, which shows this:
------------
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) 
-------------
So I assumed I had to put the call for wait_for_post_commit *before* the assertUnorderedResultSet call on line 6764.

The delete-commit it would affect is then not the delete call right before ((original file line 6760/6761):  s.executeUpdate("delete from a where a = 2 or a = 4 or a = 6");)
Because, as you say, there's no commit for that one yet.
Instead it would be for the earlier delete (original file line 6689/6690):   
         s.executeUpdate(
            "delete from a where a = 4"); 
which got committed on line (again, original file numbers:) 6732.

Still, there's no good explanation for the placing of the other wait_for_commit calls. I will make a new patch that does the call after the commit belonging to each delete - and after the commit following each deleteRow() call.


                
      was (Author: myrna):
    You're right of course.
This was because I looked at the stack trace of the original error, which shows this:
------------
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) 
-------------
So I assumed I had to put the call for wait_for_post_commit *before* the assertUnorderedResultSet call on line 6764.

The delete-commit it would affect is then not the delete call right before ((original file line 6760/6761):  s.executeUpdate("delete from a where a = 2 or a = 4 or a = 6");)
Because, as you say, there's no commit for that one yet.
Instead it would be for the earlier delete (original file line 6689/6690):   
         s.executeUpdate(
            "delete from a where a = 4"); 
which got committed on line (again, original file numbers:) 6732.

Still, there's no good explanation for the placing of the other wait_for_commit calls. I will make a new patch that does the call after the commit belonging to each delete - and after each deleteRow() call.


                  
> 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.2.3
>            Reporter: Mike Matrigali
>         Attachments: DERBY-5667.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 is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira