Derby
  1. Derby
  2. DERBY-3970

PositionedStoreStream doesn't initialize itself properly

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Minor Minor
    • Resolution: Fixed
    • Affects Version/s: 10.3.3.0, 10.4.2.0, 10.5.1.1
    • Fix Version/s: 10.4.2.1, 10.5.1.1
    • Component/s: JDBC
    • Labels:
      None

      Description

      When a PositionedStoreStream is created on top of a stream from store, it must properly initialize itself.
      Proper initialization consists of initializing and resetting the stream to make sure the states of the streams are in sync.

      A case of out of sync stream states was detected in a test where the Clob reference wasn't kept, but a new Clob object was created for each operation, i.e:
      rs.getClob(1).length();
      rs.getClob(1).getSubString(...);

      A symptom of out of sync stream states is EOFException on a valid request.
      I don't think the access style above is supposed to work, but the proper initialization should be performed anyway.

        Issue Links

          Activity

          Hide
          Kristian Waagan added a comment -

          Patch 1a performs the initialization in the constructor and adjusts the calling code.
          It also removed the resetting of the position variable in initStream, as only the first call will actually ensure the position of the underlying stream is set to zero. Subsequent calls are no-ops.

          Patch ready for review.

          Show
          Kristian Waagan added a comment - Patch 1a performs the initialization in the constructor and adjusts the calling code. It also removed the resetting of the position variable in initStream, as only the first call will actually ensure the position of the underlying stream is set to zero. Subsequent calls are no-ops. Patch ready for review.
          Hide
          Kristian Waagan added a comment -

          Tests ran without errors (derbyall, suites.All).

          Committed patch 1a to trunk with revision 722812.

          Show
          Kristian Waagan added a comment - Tests ran without errors (derbyall, suites.All). Committed patch 1a to trunk with revision 722812.
          Hide
          Kristian Waagan added a comment -

          Backported fix 1a to 10.4 with revision 725286.
          Regression tests ran cleanly on the 10.4 branch.

          Show
          Kristian Waagan added a comment - Backported fix 1a to 10.4 with revision 725286. Regression tests ran cleanly on the 10.4 branch.
          Hide
          Kristian Waagan added a comment -

          The patch cannot be backported cleanly to 10.3, and I suggest not to hand merge to get the fix into the branch.
          If anyone disagrees, I think a manual merge is relatively easy. In general, the LOB machinery has now changed so much that it's getting hard to backport the fixes to 10.3.

          Unless I hear anything, I will close the issue in a few days.

          Show
          Kristian Waagan added a comment - The patch cannot be backported cleanly to 10.3, and I suggest not to hand merge to get the fix into the branch. If anyone disagrees, I think a manual merge is relatively easy. In general, the LOB machinery has now changed so much that it's getting hard to backport the fixes to 10.3. Unless I hear anything, I will close the issue in a few days.
          Hide
          Kristian Waagan added a comment -

          Closing issue.

          Show
          Kristian Waagan added a comment - Closing issue.

            People

            • Assignee:
              Kristian Waagan
              Reporter:
              Kristian Waagan
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development