Derby
  1. Derby
  2. DERBY-2111

EOFException when using stream as parameter for multi-row update statement in embedded driver

    Details

    • Type: Bug Bug
    • Status: Open
    • Priority: Minor Minor
    • Resolution: Unresolved
    • Affects Version/s: 10.2.1.6, 10.3.1.4
    • Fix Version/s: None
    • Component/s: SQL
    • Environment:
      Embedded JDBC driver
      Derby >= 10.3: also seen with the client driver
    • Urgency:
      Normal
    • Issue & fix info:
      Repro attached
    • Bug behavior facts:
      Regression

      Description

      If a stream is used as parameter to an update statement that will update several rows, the update statement will fail.
      I will attach a JUNIT test that reproduces this error. This only fails with the embedded driver. It works well with the client driver. The exception I get is:

      There was 1 error:
      1) testMultipleUpdates(org.apache.derbyTesting.functionTests.tests.jdbcapi.streamtest)ERROR XSDA4: An unexpected exception was thrown
      at org.apache.derby.iapi.error.StandardException.newException(StandardException.java:298)
      at org.apache.derby.impl.store.raw.data.UpdateOperation.<init>(UpdateOperation.java:110)
      at org.apache.derby.impl.store.raw.data.LoggableActions.actionUpdate(LoggableActions.java:80)
      at org.apache.derby.impl.store.raw.data.StoredPage.doUpdateAtSlot(StoredPage.java:8537)
      at org.apache.derby.impl.store.raw.data.BasePage.updateAtSlot(BasePage.java:1111)
      at org.apache.derby.impl.store.access.conglomerate.GenericConglomerateController.replace(GenericConglomerateController.java:479)
      at org.apache.derby.impl.sql.execute.RowChangerImpl.updateRow(RowChangerImpl.java:523)
      at org.apache.derby.impl.sql.execute.UpdateResultSet.collectAffectedRows(UpdateResultSet.java:579)
      at org.apache.derby.impl.sql.execute.UpdateResultSet.open(UpdateResultSet.java:273)
      at org.apache.derby.impl.sql.GenericPreparedStatement.execute(GenericPreparedStatement.java:358)
      at org.apache.derby.impl.jdbc.EmbedStatement.executeStatement(EmbedStatement.java:1182)
      at org.apache.derby.impl.jdbc.EmbedPreparedStatement.executeStatement(EmbedPreparedStatement.java:1635)
      at org.apache.derby.impl.jdbc.EmbedPreparedStatement.executeUpdate(EmbedPreparedStatement.java:299)
      at org.apache.derbyTesting.functionTests.tests.jdbcapi.streamtest.testMultipleUpdates(streamtest.java:83)
      at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
      at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
      at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
      at org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:76)
      at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22)
      at junit.extensions.TestSetup$1.protect(TestSetup.java:19)
      at junit.extensions.TestSetup.run(TestSetup.java:23)

      The underlying error is:

      .java.io.EOFException: Stream has already been read and end-of-file reached and cannot be re-used.
      at org.apache.derby.iapi.types.ReaderToUTF8Stream.read(ReaderToUTF8Stream.java:185)
      at org.apache.derby.impl.store.raw.data.MemByteHolder.write(MemByteHolder.java:146)
      at org.apache.derby.impl.store.raw.data.RememberBytesInputStream.fillBuf(RememberBytesInputStream.java:135)
      at org.apache.derby.impl.store.raw.data.StoredPage.logColumn(StoredPage.java:6155)
      at org.apache.derby.impl.store.raw.data.StoredPage.logRow(StoredPage.java:3959)
      at org.apache.derby.impl.store.raw.data.UpdateOperation.writeOptionalDataToBuffer(UpdateOperation.java:255)
      at org.apache.derby.impl.store.raw.data.UpdateOperation.<init>(UpdateOperation.java:106)
      at org.apache.derby.impl.store.raw.data.LoggableActions.actionUpdate(LoggableActions.java:80)
      at org.apache.derby.impl.store.raw.data.StoredPage.doUpdateAtSlot(StoredPage.java:8537)
      at org.apache.derby.impl.store.raw.data.BasePage.updateAtSlot(BasePage.java:1111)
      at org.apache.derby.impl.store.access.conglomerate.GenericConglomerateController.replace(GenericConglomerateController.java:479)
      at org.apache.derby.impl.sql.execute.RowChangerImpl.updateRow(RowChangerImpl.java:523)
      at org.apache.derby.impl.sql.execute.UpdateResultSet.collectAffectedRows(UpdateResultSet.java:579)
      at org.apache.derby.impl.sql.execute.UpdateResultSet.open(UpdateResultSet.java:273)
      at org.apache.derby.impl.sql.GenericPreparedStatement.execute(GenericPreparedStatement.java:358)
      at org.apache.derby.impl.jdbc.EmbedStatement.executeStatement(EmbedStatement.java:1182)
      at org.apache.derby.impl.jdbc.EmbedPreparedStatement.executeStatement(EmbedPreparedStatement.java:1635)
      at org.apache.derby.impl.jdbc.EmbedPreparedStatement.executeUpdate(EmbedPreparedStatement.java:299)
      at org.apache.derbyTesting.functionTests.tests.jdbcapi.streamtest.testMultipleUpdates(streamtest.java:83)
      at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
      at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
      at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
      at java.lang.reflect.Method.invoke(Method.java:585)
      at junit.framework.TestCase.runTest(TestCase.java:154)
      at junit.framework.TestCase.runBare(TestCase.java:127)
      at org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:76)
      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 junit.extensions.TestDecorator.basicRun(TestDecorator.java:22)
      at junit.extensions.TestSetup$1.protect(TestSetup.java:19)
      at junit.framework.TestResult.runProtected(TestResult.java:124)
      at junit.extensions.TestSetup.run(TestSetup.java:23)
      at junit.framework.TestSuite.runTest(TestSuite.java:208)
      at junit.framework.TestSuite.run(TestSuite.java:203)
      at junit.textui.TestRunner.doRun(TestRunner.java:116)
      at junit.textui.TestRunner.start(TestRunner.java:172)
      at junit.textui.TestRunner.main(TestRunner.java:138)

      I assume this indicates that the stream is used directly to update a row, and that it fails when trying to use the same stream for the second row. The reason it does not fail in the client driver is that the stream is not passed to the server, it is just used to instantiate the LOB in memory.

      1. streamtest.java
        3 kB
        Øystein Grøvlen
      2. updateWithStream.java
        3 kB
        Kathey Marsden

        Issue Links

          Activity

          Hide
          Øystein Grøvlen added a comment -

          This attached JUNIT test reproduces the bug.

          Show
          Øystein Grøvlen added a comment - This attached JUNIT test reproduces the bug.
          Hide
          Andrew McIntyre added a comment -

          Unsetting Fix Version on unassigned issues.

          Show
          Andrew McIntyre added a comment - Unsetting Fix Version on unassigned issues.
          Hide
          Øystein Grøvlen added a comment -

          I am not quite sure how to fix this problem. One way would be to make a copy of the stream when it is read the first time. However, in most cases that would give an unecessary overhead since I would think most streams will only be used for a single row. This could be improved a bit, if one only made a copy when the compiler cannot determine that only one row will be affected, but I suspect that this would not catch all cases, and that many existing applications would see reduced LOB performance.

          An alternative could be to not fix the problem, but to improve the error message to be more helpful to the users.

          Show
          Øystein Grøvlen added a comment - I am not quite sure how to fix this problem. One way would be to make a copy of the stream when it is read the first time. However, in most cases that would give an unecessary overhead since I would think most streams will only be used for a single row. This could be improved a bit, if one only made a copy when the compiler cannot determine that only one row will be affected, but I suspect that this would not catch all cases, and that many existing applications would see reduced LOB performance. An alternative could be to not fix the problem, but to improve the error message to be more helpful to the users.
          Hide
          Mike Matrigali added a comment -

          Any fix should preserve the current performance for a single row update (ie. it should only read the stream once and use it to directly update store). I don't know how hard it is to recognize ahead of doing the 1st update that a second update may be necessary. The
          actual value assuming the stream has been used to update a column is available from the table and could be read back from
          the store for subsequent updates - if anyone thinks this is necessary.

          Anyone know what other db's do with streams too big for memory in this case?

          Show
          Mike Matrigali added a comment - Any fix should preserve the current performance for a single row update (ie. it should only read the stream once and use it to directly update store). I don't know how hard it is to recognize ahead of doing the 1st update that a second update may be necessary. The actual value assuming the stream has been used to update a column is available from the table and could be read back from the store for subsequent updates - if anyone thinks this is necessary. Anyone know what other db's do with streams too big for memory in this case?
          Hide
          Kathey Marsden added a comment -

          I saw this with a single row update for Clobs with setCharacterStream. See attached repro updateWithStream.

          Show
          Kathey Marsden added a comment - I saw this with a single row update for Clobs with setCharacterStream. See attached repro updateWithStream.
          Hide
          Kathey Marsden added a comment -

          I see. even though I had one row in my table it will fail with

          PreparedStatement ps2 = conn.prepareStatement("update LOB1 set c_lob = ? ");
          but passes ok with:
          PreparedStatement ps2 = conn.prepareStatement("update LOB1 set c_lob = ? where str1 = '" + clobSize + "'");

          in the repro program.

          Show
          Kathey Marsden added a comment - I see. even though I had one row in my table it will fail with PreparedStatement ps2 = conn.prepareStatement("update LOB1 set c_lob = ? "); but passes ok with: PreparedStatement ps2 = conn.prepareStatement("update LOB1 set c_lob = ? where str1 = '" + clobSize + "'"); in the repro program.
          Hide
          Daniel John Debrunner added a comment -

          Doesn't the updateWithStream test case involve multiple rows, since each testClob() call will insert a new row, and no deletes are ever performed against the table?

          Show
          Daniel John Debrunner added a comment - Doesn't the updateWithStream test case involve multiple rows, since each testClob() call will insert a new row, and no deletes are ever performed against the table?
          Hide
          Kathey Marsden added a comment -

          You are right. I am not sure how I lost that delete statement. Please ignore the noise.

          Show
          Kathey Marsden added a comment - You are right. I am not sure how I lost that delete statement. Please ignore the noise.
          Hide
          Knut Anders Hatlen added a comment -

          Triaged for 10.5.2.

          For Derby 10.3 and later, the same failure is seen with the client driver, so I'm marking this as a regression.

          Show
          Knut Anders Hatlen added a comment - Triaged for 10.5.2. For Derby 10.3 and later, the same failure is seen with the client driver, so I'm marking this as a regression.

            People

            • Assignee:
              Unassigned
              Reporter:
              Øystein Grøvlen
            • Votes:
              1 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

              • Created:
                Updated:

                Development