Uploaded image for project: 'Derby'
  1. Derby
  2. DERBY-3749

in holdable cursor selecting multiple rows with streaming blobs and clobs a commit may cause later row's streams to be broken

    Details

    • Type: Bug
    • Status: Closed
    • Priority: Minor
    • Resolution: Duplicate
    • Affects Version/s: 10.5.1.1
    • Fix Version/s: None
    • Component/s: None
    • Labels:
      None

      Description

      In a query returning multiple rows from a table, where later rows in the select loop after the commit contain streaming clobs or blobs a commit may
      attempts to get at those streams after the commit to fail with a:
      3)java.sql.SQLException: The data in this BLOB or CLOB is no longer available.
      The BLOB/CLOB's transaction may be committed, or its connection is closed.

      1. Derby3650Test.java
        13 kB
        Mike Matrigali

        Issue Links

          Activity

          Hide
          mikem Mike Matrigali added a comment - - edited

          I ran into this bug while trying to fix DERBY-3650 (thus the name of the attached test case). The testBlobSelect*Commit() and testClobSelect*Commit() cases where a commit is performed after finishing with the object show this bug. If I get time I will narrow down/rename the test, but
          figured it was better to post what I had than wait.

          I am pretty sure that this commit issue is separate from the multiple reference issue, that is the point of DERBY-3650.

          Show
          mikem Mike Matrigali added a comment - - edited I ran into this bug while trying to fix DERBY-3650 (thus the name of the attached test case). The testBlobSelect*Commit() and testClobSelect*Commit() cases where a commit is performed after finishing with the object show this bug. If I get time I will narrow down/rename the test, but figured it was better to post what I had than wait. I am pretty sure that this commit issue is separate from the multiple reference issue, that is the point of DERBY-3650 .
          Hide
          mikem Mike Matrigali added a comment -

          I anyone gets a chance to look at this the first thing I would track down is if this is a bulk fetch issue. By that I mean are
          N streams getting created for N rows before even the first is returned to the user. For performance bulk fetch is the usual
          way language gets rows out of the store. Then when the commit happens each
          of these "open" streams gets closed.

          Reading through the code I don't think these streams have any support for holdability. Most of the hodability support is
          located in the language and access layer. For instance in the case of an access fetch loop there is code everytime the
          loop is reentered to check if it is a holdable cursor and if so to reopen the underlying resource.

          My assumption is that this has been broken for many releases, but have not had a chance to check yet.

          Show
          mikem Mike Matrigali added a comment - I anyone gets a chance to look at this the first thing I would track down is if this is a bulk fetch issue. By that I mean are N streams getting created for N rows before even the first is returned to the user. For performance bulk fetch is the usual way language gets rows out of the store. Then when the commit happens each of these "open" streams gets closed. Reading through the code I don't think these streams have any support for holdability. Most of the hodability support is located in the language and access layer. For instance in the case of an access fetch loop there is code everytime the loop is reentered to check if it is a holdable cursor and if so to reopen the underlying resource. My assumption is that this has been broken for many releases, but have not had a chance to check yet.
          Hide
          knutanders Knut Anders Hatlen added a comment -

          I think this is a duplicate of DERBY-1511.

          Show
          knutanders Knut Anders Hatlen added a comment - I think this is a duplicate of DERBY-1511 .
          Hide
          knutanders Knut Anders Hatlen added a comment -

          There hasn't been any objections to my comment about this issue being a duplicate of DERBY-1511, so I'm setting resolution to "Duplicate".

          Show
          knutanders Knut Anders Hatlen added a comment - There hasn't been any objections to my comment about this issue being a duplicate of DERBY-1511 , so I'm setting resolution to "Duplicate".

            People

            • Assignee:
              Unassigned
              Reporter:
              mikem Mike Matrigali
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development