Derby
  1. Derby
  2. DERBY-3469

Clob.length() doesn't detect a closed underlying connection in a consistent way

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Minor Minor
    • Resolution: Fixed
    • Affects Version/s: 10.3.2.1, 10.4.1.3, 10.5.1.1
    • Fix Version/s: 10.4.2.0, 10.5.1.1
    • Component/s: JDBC, Network Client
    • Labels:
      None
    • Environment:
      Client-driver

      Description

      Depending on the state of the Clob, the method length gives two different SQL states when the underlying connection has been closed.
      According to BlobClob4BlobTest.testClobAfterConnectionClose, it should throw 08003 (no current connection), but it might also throw XJ215 (invalid lob).

      I think this is caused indirectly by the following method in Lob:
      long sqlLength() throws SqlException
      {
      if (lengthObtained_) return sqlLength_;

      if (isLocator())

      { sqlLength_ = getLocatorLength(); lengthObtained_ = true; }

      else if (willBeLayerBStreamed())

      { throw new SqlException(agent_.logWriter_, LOB_OBJECT_LENGTH_UNKNOWN_YET); }

      else

      { materializeStream(); // Will set sqlLength_ }

      return sqlLength_;
      }

      In this method, getLocatorLength will check for a closed connection (somewhere down in prepareCallX i believe), whereas the cached length is returned if it has already been determined. Clob.length does not check for a closed connection.
      There are multiple fixes, but I think a proper investigation should be carried out before a solution is chosen.

      1. ClosedClobTest.java
        2 kB
        Kristian Waagan
      2. ClosedClobTest.java
        4 kB
        Kristian Waagan

        Issue Links

          Activity

          Hide
          Kristian Waagan added a comment -

          Attached a very simple repro ('ClosedClobTest.java').
          To use it with the client driver, you must do two things:
          1) Start you own network server.
          2) Supply an argument to the repro (doesn't matter what it is)

          Sorry for the rather bad quality of the repro, but it should demonstrate the problem.
          Note that you must comment/uncomment the various parts to run the different scenarios.

          Show
          Kristian Waagan added a comment - Attached a very simple repro ('ClosedClobTest.java'). To use it with the client driver, you must do two things: 1) Start you own network server. 2) Supply an argument to the repro (doesn't matter what it is) Sorry for the rather bad quality of the repro, but it should demonstrate the problem. Note that you must comment/uncomment the various parts to run the different scenarios.
          Hide
          Kristian Waagan added a comment -

          Added a link to DERBY-3574, as the problem there seems to be in the same area of the code.

          Show
          Kristian Waagan added a comment - Added a link to DERBY-3574 , as the problem there seems to be in the same area of the code.
          Hide
          V.Narayanan added a comment -

          This issue will have unexpected ramifications for the update sensitive Clob and Blob streams.

          The update sensitive streams upon creation depend on the sqlLength() method to determine the
          validity of the underlying Lob. If the sqlLength method returns the cached length value these
          streams will not fail upon creation (getBinaryStream() and other methods) but when a read or
          write is called upon them. I think they should uniformly fail when getBinaryStream() is called.

          A easy way I can think of resolving this problem is to reset the "lengthObtained_" boolean, when
          free(). This would ensure that the cached value is not used after a free is called.

          I would design this by introducing a free() method in Lob and setting lengthObtained_=false in that
          method and do a super.free() in the free methods of am/Clob and am/Blob.

          I have not tested this solution yet, but it seems OK to me at first look.

          Show
          V.Narayanan added a comment - This issue will have unexpected ramifications for the update sensitive Clob and Blob streams. The update sensitive streams upon creation depend on the sqlLength() method to determine the validity of the underlying Lob. If the sqlLength method returns the cached length value these streams will not fail upon creation (getBinaryStream() and other methods) but when a read or write is called upon them. I think they should uniformly fail when getBinaryStream() is called. A easy way I can think of resolving this problem is to reset the "lengthObtained_" boolean, when free(). This would ensure that the cached value is not used after a free is called. I would design this by introducing a free() method in Lob and setting lengthObtained_=false in that method and do a super.free() in the free methods of am/Clob and am/Blob. I have not tested this solution yet, but it seems OK to me at first look.
          Hide
          Kristian Waagan added a comment -

          Output from a version with inconsistent behavior:
          ----- Test case 1
          Get clob, get length, get substring, close connection, get length again.
          Expect to get exception at the last length call.
          #
          Clob length: 8
          Clob content: a string
          Clob length: 8
          FAILURE! No exception thrown.
          ----- Test case 2
          No autocommit, get clob, get length, get substring, free clob, get length again.
          Expect to get exception at the last length call.
          #
          Clob length: 8
          Clob content: a string
          EXCEPTION! (expected)
          You cannot invoke other java.sql.Clob/java.sql.Blob methods after calling the free() method or after the Blob/Clob's transaction has been committed or rolled back.
          ----- Test case 3
          Get clob, get length, get substring, get length, commit & close, free clob.
          Expect to get exception when calling free.
          #
          Clob length: 8
          Clob content: a string
          EXCEPTION! (expected)
          No current connection.

          Expect all exceptions to be 'No current connection'
          REPRO FAILURE!!

          Output from a version with consistent behavior:
          ----- Test case 1
          Get clob, get length, get substring, close connection, get length again.
          Expect to get exception at the last length call.
          #
          Clob length: 8
          Clob content: a string
          EXCEPTION! (expected)
          No current connection.
          ----- Test case 2
          No autocommit, get clob, get length, get substring, free clob, get length again.
          Expect to get exception at the last length call.
          #
          Clob length: 8
          Clob content: a string
          EXCEPTION! (expected)
          No current connection.
          ----- Test case 3
          Get clob, get length, get substring, get length, commit & close, free clob.
          Expect to get exception when calling free.
          #
          Clob length: 8
          Clob content: a string
          EXCEPTION! (expected)
          No current connection.

          Expect all exceptions to be 'No current connection'
          REPRO SUCCESS!!

          Show
          Kristian Waagan added a comment - Output from a version with inconsistent behavior: ----- Test case 1 Get clob, get length, get substring, close connection, get length again. Expect to get exception at the last length call. # Clob length: 8 Clob content: a string Clob length: 8 FAILURE! No exception thrown. ----- Test case 2 No autocommit, get clob, get length, get substring, free clob, get length again. Expect to get exception at the last length call. # Clob length: 8 Clob content: a string EXCEPTION! (expected) You cannot invoke other java.sql.Clob/java.sql.Blob methods after calling the free() method or after the Blob/Clob's transaction has been committed or rolled back. ----- Test case 3 Get clob, get length, get substring, get length, commit & close, free clob. Expect to get exception when calling free. # Clob length: 8 Clob content: a string EXCEPTION! (expected) No current connection. Expect all exceptions to be 'No current connection' REPRO FAILURE!! Output from a version with consistent behavior: ----- Test case 1 Get clob, get length, get substring, close connection, get length again. Expect to get exception at the last length call. # Clob length: 8 Clob content: a string EXCEPTION! (expected) No current connection. ----- Test case 2 No autocommit, get clob, get length, get substring, free clob, get length again. Expect to get exception at the last length call. # Clob length: 8 Clob content: a string EXCEPTION! (expected) No current connection. ----- Test case 3 Get clob, get length, get substring, get length, commit & close, free clob. Expect to get exception when calling free. # Clob length: 8 Clob content: a string EXCEPTION! (expected) No current connection. Expect all exceptions to be 'No current connection' REPRO SUCCESS!!
          Hide
          Kristian Waagan added a comment -

          Updating affects version and assigning to Tiago, as he fixed DERBY-3574 which also fixes this issue.

          Show
          Kristian Waagan added a comment - Updating affects version and assigning to Tiago, as he fixed DERBY-3574 which also fixes this issue.
          Hide
          Kristian Waagan added a comment -

          Closing issue. See DERBY-3574 for revision numbers.
          Ran regression tests on the 10.4 branch and trunk, and the repro succeeds on both 10.4 and trunk.

          Show
          Kristian Waagan added a comment - Closing issue. See DERBY-3574 for revision numbers. Ran regression tests on the 10.4 branch and trunk, and the repro succeeds on both 10.4 and trunk.

            People

            • Assignee:
              Tiago R. Espinha
              Reporter:
              Kristian Waagan
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development