Derby
  1. Derby
  2. DERBY-6038

Intermittent failure in LangProcedureTest: cannot drop table because of open ResultSet

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 10.10.1.1
    • Fix Version/s: 10.10.1.1
    • Component/s: Test
    • Labels:
      None
    • Bug behavior facts:
      Regression Test Failure

      Description

      Seen intermittently after LangProcedureTest was enabled:

      1) testDynamicResultSets(org.apache.derbyTesting.functionTests.tests.lang.LangProcedureTest)java.sql.SQLException: Operation 'DROP TABLE' cannot be performed on object 'DELLATER3' because there is an open ResultSet dependent on that object.
      at org.apache.derby.impl.jdbc.SQLExceptionFactory40.getSQLException(SQLExceptionFactory40.java:98)
      at org.apache.derby.impl.jdbc.Util.generateCsSQLException(Util.java:256)
      at org.apache.derby.impl.jdbc.TransactionResourceImpl.wrapInSQLException(TransactionResourceImpl.java:424)
      at org.apache.derby.impl.jdbc.TransactionResourceImpl.handleException(TransactionResourceImpl.java:353)
      at org.apache.derby.impl.jdbc.EmbedConnection.handleException(EmbedConnection.java:2400)
      at org.apache.derby.impl.jdbc.ConnectionChild.handleException(ConnectionChild.java:82)
      at org.apache.derby.impl.jdbc.EmbedStatement.executeStatement(EmbedStatement.java:1334)
      at org.apache.derby.impl.jdbc.EmbedStatement.execute(EmbedStatement.java:630)
      at org.apache.derby.impl.jdbc.EmbedStatement.execute(EmbedStatement.java:559)
      at org.apache.derbyTesting.functionTests.tests.lang.LangProcedureTest.testDynamicResultSets(LangProcedureTest.java:976)
      at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
      at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
      at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
      at org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:117)
      at org.apache.derbyTesting.junit.BaseJDBCTestCase.runBareOverridable(BaseJDBCTestCase.java:424)
      at org.apache.derbyTesting.junit.BaseJDBCTestCase.runBare(BaseJDBCTestCase.java:441)
      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)
      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)
      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)
      Caused by: java.sql.SQLException: Operation 'DROP TABLE' cannot be performed on object 'DELLATER3' because there is an open ResultSet dependent on that object.
      at org.apache.derby.impl.jdbc.SQLExceptionFactory.getSQLException(SQLExceptionFactory.java:42)
      at org.apache.derby.impl.jdbc.SQLExceptionFactory40.wrapArgsForTransportAcrossDRDA(SQLExceptionFactory40.java:122)
      at org.apache.derby.impl.jdbc.SQLExceptionFactory40.getSQLException(SQLExceptionFactory40.java:71)
      ... 47 more
      Caused by: ERROR X0X95: Operation 'DROP TABLE' cannot be performed on object 'DELLATER3' because there is an open ResultSet dependent on that object.
      at org.apache.derby.iapi.error.StandardException.newException(StandardException.java:295)
      at org.apache.derby.impl.sql.conn.GenericLanguageConnectionContext.verifyNoOpenResultSets(GenericLanguageConnectionContext.java:2146)
      at org.apache.derby.impl.sql.GenericPreparedStatement.prepareToInvalidate(GenericPreparedStatement.java:778)
      at org.apache.derby.impl.sql.depend.BasicDependencyManager.coreInvalidateFor(BasicDependencyManager.java:437)
      at org.apache.derby.impl.sql.depend.BasicDependencyManager.invalidateFor(BasicDependencyManager.java:298)
      at org.apache.derby.impl.sql.execute.DropTableConstantAction.executeConstantAction(DropTableConstantAction.java:265)
      at org.apache.derby.impl.sql.execute.MiscResultSet.open(MiscResultSet.java:61)
      at org.apache.derby.impl.sql.GenericPreparedStatement.executeStmt(GenericPreparedStatement.java:452)
      at org.apache.derby.impl.sql.GenericPreparedStatement.execute(GenericPreparedStatement.java:333)
      at org.apache.derby.impl.jdbc.EmbedStatement.executeStatement(EmbedStatement.java:1242)
      ... 41 more

      1. d6038-1a-close-rs.diff
        3 kB
        Knut Anders Hatlen

        Issue Links

          Activity

          Hide
          Knut Anders Hatlen added a comment -

          It reproduces every time in my environment if I run the test with -XX:+DisableExplicitGC. That switch disables a workaround in GenericLanguageConnectionContext.verifyNoOpenResultSets() that runs garbage collection to give the ResultSet a last chance to get closed before raising the error. The workaround is not 100% reliable, since calling System.gc() and System.runFinalization() is just a suggestion to the JVM, according to the Java SE javadocs. That's probably why the test occasionally fails also when it's run without the switch.

          Show
          Knut Anders Hatlen added a comment - It reproduces every time in my environment if I run the test with -XX:+DisableExplicitGC. That switch disables a workaround in GenericLanguageConnectionContext.verifyNoOpenResultSets() that runs garbage collection to give the ResultSet a last chance to get closed before raising the error. The workaround is not 100% reliable, since calling System.gc() and System.runFinalization() is just a suggestion to the JVM, according to the Java SE javadocs. That's probably why the test occasionally fails also when it's run without the switch.
          Show
          Knut Anders Hatlen added a comment - Also seen in the nightly tests: http://download.java.net/javadesktop/derby/javadb-5570895-report/javadb-5570895-3573399-details.html
          Hide
          Knut Anders Hatlen added a comment -

          One of the test cases for DERBY-3304 calls a stored Java procedure that raises an exception. The comments in the test case indicate that it expected all open result sets produced in the stored procedure to be closed automatically when the exception is raised. However, the fix for DERBY-3304 only ensured that the CallStatementResultSet and all of its dynamic result sets would be closed automatically if the procedure failed. It would give the impression of having closed the other result sets opened in the procedure, because gc would in most cases close them implicitly before the table was attempted dropped, but not always.

          The attached patch makes the procedure close the non-dynamic result set explicitly to prevent the intermittent failure. It also updates the comments to say that the fix for DERBY-3304 only affected the internal CallStatementResultSet and the dynamic result sets in the procedure. This makes the test run cleanly in my environment, also with the JVM switch that reliably reproduced the failure.

          Show
          Knut Anders Hatlen added a comment - One of the test cases for DERBY-3304 calls a stored Java procedure that raises an exception. The comments in the test case indicate that it expected all open result sets produced in the stored procedure to be closed automatically when the exception is raised. However, the fix for DERBY-3304 only ensured that the CallStatementResultSet and all of its dynamic result sets would be closed automatically if the procedure failed. It would give the impression of having closed the other result sets opened in the procedure, because gc would in most cases close them implicitly before the table was attempted dropped, but not always. The attached patch makes the procedure close the non-dynamic result set explicitly to prevent the intermittent failure. It also updates the comments to say that the fix for DERBY-3304 only affected the internal CallStatementResultSet and the dynamic result sets in the procedure. This makes the test run cleanly in my environment, also with the JVM switch that reliably reproduced the failure.
          Hide
          Dag H. Wanvik added a comment -

          Thanks, Knut. Analysis and patch looks correct to me. +1

          Show
          Dag H. Wanvik added a comment - Thanks, Knut. Analysis and patch looks correct to me. +1
          Hide
          Knut Anders Hatlen added a comment -

          Thanks, Dag. Committed revision 1431945.

          Show
          Knut Anders Hatlen added a comment - Thanks, Dag. Committed revision 1431945.

            People

            • Assignee:
              Knut Anders Hatlen
              Reporter:
              Knut Anders Hatlen
            • Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development