Derby
  1. Derby
  2. DERBY-965

DatabaseMetadata method supportsResultSetConcurrency returns wrong result on network client

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Minor Minor
    • Resolution: Fixed
    • Affects Version/s: 10.2.1.6
    • Fix Version/s: 10.2.1.6
    • Labels:
      None
    • Environment:
      Solaris 10, x86, Sun JDK 1.4.2

      Description

      The DatabaseMetaData method supportsResultSetConcurrency erroneously
      returns false on the network client for all arguments combination, cf
      the attached repro program. The embedded client returns correct
      results, viz the output:

      org.apache.derby.jdbc.ClientDriver:
      SupportsResultSetConcurrency: TYPE_FORWARD_ONLY,CONCUR_READ_ONLY: false
      SupportsResultSetConcurrency: TYPE_FORWARD_ONLY,CONCUR_UPDATABLE: false
      SupportsResultSetConcurrency: TYPE_SCROLL_INSENSITIVE,CONCUR_READ_ONLY: false
      SupportsResultSetConcurrency: TYPE_SCROLL_INSENSITIVE,CONCUR_UPDATABLE: false
      SupportsResultSetConcurrency: TYPE_SCROLL_SENSITIVE,CONCUR_READ_ONLY: false
      SupportsResultSetConcurrency: TYPE_SCROLL_SENSITIVE,CONCUR_UPDATABLE: false
      org.apache.derby.jdbc.EmbeddedDriver:
      SupportsResultSetConcurrency: TYPE_FORWARD_ONLY,CONCUR_READ_ONLY: true
      SupportsResultSetConcurrency: TYPE_FORWARD_ONLY,CONCUR_UPDATABLE: true
      SupportsResultSetConcurrency: TYPE_SCROLL_INSENSITIVE,CONCUR_READ_ONLY: true
      SupportsResultSetConcurrency: TYPE_SCROLL_INSENSITIVE,CONCUR_UPDATABLE: false
      SupportsResultSetConcurrency: TYPE_SCROLL_SENSITIVE,CONCUR_READ_ONLY: false
      SupportsResultSetConcurrency: TYPE_SCROLL_SENSITIVE,CONCUR_UPDATABLE: false

      Presumably, this is wrong in released versions as well.

      1. derby965b-v1.diff
        1 kB
        Dag H. Wanvik
      2. derby965b-v1.stat
        0.1 kB
        Dag H. Wanvik
      3. derby965-v2.diff
        14 kB
        Dag H. Wanvik
      4. derby965-v2.stat
        0.7 kB
        Dag H. Wanvik
      5. derby965-v1.diff
        14 kB
        Dag H. Wanvik
      6. derby965-v1.stat
        0.8 kB
        Dag H. Wanvik
      7. Main.java
        3 kB
        Dag H. Wanvik

        Issue Links

          Activity

          Hide
          Dag H. Wanvik added a comment -

          verified on trunk

          Show
          Dag H. Wanvik added a comment - verified on trunk
          Hide
          Knut Anders Hatlen added a comment -

          Verified that the phaseTester diff was reduced by the patch.

          Committed revision 382759.

          Show
          Knut Anders Hatlen added a comment - Verified that the phaseTester diff was reduced by the patch. Committed revision 382759.
          Hide
          Dag H. Wanvik added a comment -

          This patch (derby965b-v1) updates the master for phaseTester.java.
          This test is not part of derbyall and the master must be manually
          compared with the output of the phase tests, cf description in
          DERBY-573.

          phaseTester runs metadata_test.java as part of its work, so the master
          needs to be updated whenever metadata_test.java changes (as this issue
          does).

          Note: Even with this patch, phaseTester when run as described,
          failed. I noticed the following:

          • the shell script driving it is WIndows specific (";" as classpath
            delimiter)
          • in the soft upgrade phase, the metadata test fails (table not
            found), when performing a stored procedure: 'CALL
            SYSIBM.SQLCOLPRIVILEGES' (in odbc_metadata#getMetadataRS).

          This patch lessens the diff between the master and the "current"
          output, though, so i think it should be committed.

          Show
          Dag H. Wanvik added a comment - This patch (derby965b-v1) updates the master for phaseTester.java. This test is not part of derbyall and the master must be manually compared with the output of the phase tests, cf description in DERBY-573 . phaseTester runs metadata_test.java as part of its work, so the master needs to be updated whenever metadata_test.java changes (as this issue does). Note: Even with this patch, phaseTester when run as described, failed. I noticed the following: the shell script driving it is WIndows specific (";" as classpath delimiter) in the soft upgrade phase, the metadata test fails (table not found), when performing a stored procedure: 'CALL SYSIBM.SQLCOLPRIVILEGES' (in odbc_metadata#getMetadataRS). This patch lessens the diff between the master and the "current" output, though, so i think it should be committed.
          Hide
          Deepa Remesh added a comment -

          I just started to look at DERBY-514 for upgrade tests and was trying to see how the phaseTester test currently works. For the following question from Dag:

          "I noticed the canon of phaseTester also contain metadata_test output, but I did not update this test's canon, as I am not familiar with how it should be updated. I'd appreciate advice on that."

          please see if this comment in DERBY-573 helps: http://issues.apache.org/jira/browse/DERBY-573#action_12360193

          Show
          Deepa Remesh added a comment - I just started to look at DERBY-514 for upgrade tests and was trying to see how the phaseTester test currently works. For the following question from Dag: "I noticed the canon of phaseTester also contain metadata_test output, but I did not update this test's canon, as I am not familiar with how it should be updated. I'd appreciate advice on that." please see if this comment in DERBY-573 helps: http://issues.apache.org/jira/browse/DERBY-573#action_12360193
          Hide
          Knut Anders Hatlen added a comment -

          Committed revision 382319.

          I didn't mark the issue as resolved because of the unanswered question
          about the phaseTester canon.

          Show
          Knut Anders Hatlen added a comment - Committed revision 382319. I didn't mark the issue as resolved because of the unanswered question about the phaseTester canon.
          Hide
          Dag H. Wanvik added a comment -

          Note: I did not get any answer to my question on the phaseTester canon,
          as far as I can see.

          Show
          Dag H. Wanvik added a comment - Note: I did not get any answer to my question on the phaseTester canon, as far as I can see.
          Hide
          Knut Anders Hatlen added a comment -

          It seems like Dag has addressed the concerns of the reviewers. I'm
          planning to commit this patch tomorrow, so please scream out if you
          still have issues with it.

          Show
          Knut Anders Hatlen added a comment - It seems like Dag has addressed the concerns of the reviewers. I'm planning to commit this patch tomorrow, so please scream out if you still have issues with it.
          Hide
          Dag H. Wanvik added a comment -

          A new patch which replaces v1.

          Description:

          • skips added test lines for supportsResultSetConcurrency
            in metadata_test.java for jcc client
          • contains added comments as suggested by Bryan

          Tests:

          Derbyall runs correctly on Sun Solaris 10/x86, JVM 1.4.2.

          I also ran the repro with mixed client server versions [10.1.2.1 - (330608), trunk at
          10.2.0.0 alpha - (380154M)] and got the expected result:

          Running with a new client against an old server the repro: No longer only false; values are wrong
          of course, but now correctly reflect (old) server's values.

          Server is ready to accept connections on port 1500.
          Connection number: 1.
          Connection number: 2.
          org.apache.derby.jdbc.ClientDriver:
          SupportsResultSetConcurrency: TYPE_FORWARD_ONLY,CONCUR_READ_ONLY: false
          SupportsResultSetConcurrency: TYPE_FORWARD_ONLY,CONCUR_UPDATABLE: true
          SupportsResultSetConcurrency: TYPE_SCROLL_INSENSITIVE,CONCUR_READ_ONLY: false
          SupportsResultSetConcurrency: TYPE_SCROLL_INSENSITIVE,CONCUR_UPDATABLE: true
          SupportsResultSetConcurrency: TYPE_SCROLL_SENSITIVE,CONCUR_READ_ONLY: true
          SupportsResultSetConcurrency: TYPE_SCROLL_SENSITIVE,CONCUR_UPDATABLE: true

          Running with old client and new server: Client can't make sense of the encoding (as before) and
          returns only false.

          Apache Derby Network Server - 10.2.0.0 alpha started and ready to accept connections on port 1500 at 2006-02-28 04:11:13.961 GMT

          org.apache.derby.jdbc.ClientDriver:
          SupportsResultSetConcurrency: TYPE_FORWARD_ONLY,CONCUR_READ_ONLY: false
          SupportsResultSetConcurrency: TYPE_FORWARD_ONLY,CONCUR_UPDATABLE: false
          SupportsResultSetConcurrency: TYPE_SCROLL_INSENSITIVE,CONCUR_READ_ONLY: false
          SupportsResultSetConcurrency: TYPE_SCROLL_INSENSITIVE,CONCUR_UPDATABLE: false
          SupportsResultSetConcurrency: TYPE_SCROLL_SENSITIVE,CONCUR_READ_ONLY: false
          SupportsResultSetConcurrency: TYPE_SCROLL_SENSITIVE,CONCUR_UPDATABLE: false

          Show
          Dag H. Wanvik added a comment - A new patch which replaces v1. Description: skips added test lines for supportsResultSetConcurrency in metadata_test.java for jcc client contains added comments as suggested by Bryan Tests: Derbyall runs correctly on Sun Solaris 10/x86, JVM 1.4.2. I also ran the repro with mixed client server versions [10.1.2.1 - (330608), trunk at 10.2.0.0 alpha - (380154M)] and got the expected result: Running with a new client against an old server the repro: No longer only false; values are wrong of course, but now correctly reflect (old) server's values. Server is ready to accept connections on port 1500. Connection number: 1. Connection number: 2. org.apache.derby.jdbc.ClientDriver: SupportsResultSetConcurrency: TYPE_FORWARD_ONLY,CONCUR_READ_ONLY: false SupportsResultSetConcurrency: TYPE_FORWARD_ONLY,CONCUR_UPDATABLE: true SupportsResultSetConcurrency: TYPE_SCROLL_INSENSITIVE,CONCUR_READ_ONLY: false SupportsResultSetConcurrency: TYPE_SCROLL_INSENSITIVE,CONCUR_UPDATABLE: true SupportsResultSetConcurrency: TYPE_SCROLL_SENSITIVE,CONCUR_READ_ONLY: true SupportsResultSetConcurrency: TYPE_SCROLL_SENSITIVE,CONCUR_UPDATABLE: true Running with old client and new server: Client can't make sense of the encoding (as before) and returns only false. Apache Derby Network Server - 10.2.0.0 alpha started and ready to accept connections on port 1500 at 2006-02-28 04:11:13.961 GMT org.apache.derby.jdbc.ClientDriver: SupportsResultSetConcurrency: TYPE_FORWARD_ONLY,CONCUR_READ_ONLY: false SupportsResultSetConcurrency: TYPE_FORWARD_ONLY,CONCUR_UPDATABLE: false SupportsResultSetConcurrency: TYPE_SCROLL_INSENSITIVE,CONCUR_READ_ONLY: false SupportsResultSetConcurrency: TYPE_SCROLL_INSENSITIVE,CONCUR_UPDATABLE: false SupportsResultSetConcurrency: TYPE_SCROLL_SENSITIVE,CONCUR_READ_ONLY: false SupportsResultSetConcurrency: TYPE_SCROLL_SENSITIVE,CONCUR_UPDATABLE: false
          Hide
          Dag H. Wanvik added a comment -

          Kathey wrote:

          > Your earlier comment said: Note that this raises an upgrade issue, in
          > that the existing client would crash if the server's data were
          > corrected to the encoding syntax the client expects (due to the coding
          > bug) but the patch comments made it sound less severe.

          Yes, I believe I chose the change which made the upgrade issue less
          severe: By retaining the server's encoding, old clients will not
          crash, cf. my answer to Bryan.

          > Is there a scenario with this patch where we will get a crash where we
          > did not before?

          I do not think there is with this patch. I will test 10.1 against
          trunk for both skewed version combination (client, server) to make
          sure.

          > Also I wanted to mention if you need client to behave differently with
          > different versions you can add something to
          > NetDatabaseMetaData.computeFeatureSet
          >
          > Similarly on the server side AppRequester.java has a mechanism for
          > client version specific behaviour.

          Thanks, I'll look at those. I don't think they are needed in this
          case, though.

          Show
          Dag H. Wanvik added a comment - Kathey wrote: > Your earlier comment said: Note that this raises an upgrade issue, in > that the existing client would crash if the server's data were > corrected to the encoding syntax the client expects (due to the coding > bug) but the patch comments made it sound less severe. Yes, I believe I chose the change which made the upgrade issue less severe: By retaining the server's encoding, old clients will not crash, cf. my answer to Bryan. > Is there a scenario with this patch where we will get a crash where we > did not before? I do not think there is with this patch. I will test 10.1 against trunk for both skewed version combination (client, server) to make sure. > Also I wanted to mention if you need client to behave differently with > different versions you can add something to > NetDatabaseMetaData.computeFeatureSet > > Similarly on the server side AppRequester.java has a mechanism for > client version specific behaviour. Thanks, I'll look at those. I don't think they are needed in this case, though.
          Hide
          Dag H. Wanvik added a comment -

          Thanks for looking at this Bryan.

          Bryan wrote:

          > It would be nice to have comments in metadata_net.properties
          > explaining the encoding, and in DatabaseMetaData.java explaining
          > what's going on with the string tokenizers and pointing to the
          > metadata_net.properties since the two files are sort of linked at the
          > hip.

          I'll do that and upload a new patch.

          > It's a bummer about the mixed-version incompatibilities, but I
          > couldn't think of any easy way to make them better.

          By changing the client's code the way I did (not changing the encoding
          in the server, only correcting it's value), we should be OK (cf my
          comments above):

          Old clients - new server will still give false for all combinations,
          since the value sets for CONCURRENCY and TYPE are disjoint, and the
          old client basically tries to match concurrency against type. So old
          clients will not crash. This should remove Kathey's concern, I hope

          A new client against and old server will work, but give wrong results,
          although wrong in a different way from before. It would now return
          true in some cases, where it previosuly always returned false. Those
          "true" value though, would mostly be wrong, cf. old server's values:

          TYPE_FORWARD_ONLY,CONCUR_UPDATABLE;\
          TYPE_SCROLL_INSENSITIVE,CONCUR_UPDATABLE;\
          TYPE_SCROLL_SENSITIVE,CONCUR_READ_ONLY,CONCUR_UPDATABLE

          So it would give wrong values, but the old behavior (Always false) was
          wrong too.. I think this is acceptable.

          Show
          Dag H. Wanvik added a comment - Thanks for looking at this Bryan. Bryan wrote: > It would be nice to have comments in metadata_net.properties > explaining the encoding, and in DatabaseMetaData.java explaining > what's going on with the string tokenizers and pointing to the > metadata_net.properties since the two files are sort of linked at the > hip. I'll do that and upload a new patch. > It's a bummer about the mixed-version incompatibilities, but I > couldn't think of any easy way to make them better. By changing the client's code the way I did (not changing the encoding in the server, only correcting it's value), we should be OK (cf my comments above): Old clients - new server will still give false for all combinations, since the value sets for CONCURRENCY and TYPE are disjoint, and the old client basically tries to match concurrency against type. So old clients will not crash. This should remove Kathey's concern, I hope A new client against and old server will work, but give wrong results, although wrong in a different way from before. It would now return true in some cases, where it previosuly always returned false. Those "true" value though, would mostly be wrong, cf. old server's values: TYPE_FORWARD_ONLY,CONCUR_UPDATABLE;\ TYPE_SCROLL_INSENSITIVE,CONCUR_UPDATABLE;\ TYPE_SCROLL_SENSITIVE,CONCUR_READ_ONLY,CONCUR_UPDATABLE So it would give wrong values, but the old behavior (Always false) was wrong too.. I think this is acceptable.
          Hide
          Kathey Marsden added a comment -

          I haven't been able to look at this closely to understand the issues, but I have some questions

          Your earlier comment said:
          Note that this
          raises an upgrade issue, in that the existing client would crash if
          the server's data were corrected to the encoding syntax the client
          expects (due to the coding bug) but the patch comments made it sound less severe.

          Is there a scenario with this patch where we will get a crash where we did not before?

          I know there was a lot of discussion at one time about changes to metadata.properties and metadata_net.properties for upgrade, soft upgrade and downgrade. I wonder if someone could point me to the final resolution or explain it if it is brief. I had always been a fan of drop and recreate on any version change to allow for bug fixing and prevent intractible upgrade situations.

          Also I wanted to mention if you need client to behave differently with different versions you can add something to
          NetDatabaseMetaData.computeFeatureSet

          Similarly on the server side AppRequester.java has a mechanism for client version specific behaviour.

          Show
          Kathey Marsden added a comment - I haven't been able to look at this closely to understand the issues, but I have some questions Your earlier comment said: Note that this raises an upgrade issue, in that the existing client would crash if the server's data were corrected to the encoding syntax the client expects (due to the coding bug) but the patch comments made it sound less severe. Is there a scenario with this patch where we will get a crash where we did not before? I know there was a lot of discussion at one time about changes to metadata.properties and metadata_net.properties for upgrade, soft upgrade and downgrade. I wonder if someone could point me to the final resolution or explain it if it is brief. I had always been a fan of drop and recreate on any version change to allow for bug fixing and prevent intractible upgrade situations. Also I wanted to mention if you need client to behave differently with different versions you can add something to NetDatabaseMetaData.computeFeatureSet Similarly on the server side AppRequester.java has a mechanism for client version specific behaviour.
          Hide
          Bryan Pendleton added a comment -

          I read through your changes and they seem good to me.

          It would be nice to have comments in metadata_net.properties explaining the encoding, and in DatabaseMetaData.java explaining what's going on with the string tokenizers and pointing to the metadata_net.properties since the two files are sort of linked at the hip.

          It's a bummer about the mixed-version incompatibilities, but I couldn't think of any easy way to make them better.

          Show
          Bryan Pendleton added a comment - I read through your changes and they seem good to me. It would be nice to have comments in metadata_net.properties explaining the encoding, and in DatabaseMetaData.java explaining what's going on with the string tokenizers and pointing to the metadata_net.properties since the two files are sort of linked at the hip. It's a bummer about the mixed-version incompatibilities, but I couldn't think of any easy way to make them better.
          Hide
          Dag H. Wanvik added a comment -
          • The patch, derby965-v1. {stat,diff}

            , corrects the server data to the correct values,
            retaining the encoding used on the server side. The new values
            (metadata_net.properties) now reflect the capabilities of the
            server+network client driver::

          '1003,1007,1008;1004,1007;1005'
          i.e. decoded:

          TYPE_FORWARD_ONLY,CONCUR_READ_ONLY,CONCUR_UPDATABLE;
          TYPE_SCROLL_INSENSITIVE,CONCUR_READ_ONLY
          TYPE_SCROLL_SENSITIVE

          DERBY-775 (client SUR) will be adding CONCUR_UPDATABLE to the second
          line later.

          • The client's parsing and decoding has been changed to comply with
            this encoding style and now gives the correct result
            (changes in getMetaDataInfoInt_SupportsResultSetConcurrency).
          • This patch should not give upgrade problems, in that an older client
            against a new server will give the same (wrong) results as before when
            trying to interpret type as concurrency. A new client against and old
            server will work, but give wrong results, although wrong in a
            different way from before. cf. the analysis of feb-13
            above. Presumably, apps relying on this method would have failed
            always, so the changed result should not be too serious.
          • Tests of this method has been added to metadata_test.java and
            embedded and derby network client canons have been
            updated.
          • NOTE: Unfortunately, derbynetmats running the JCC client seems to
            have the same problem (it returns false for all type, concurrency
            combinations), so I had to make derbynetmats skip these new tests for
            that driver.
          • derbyall has been run successfully on Sun's 1.4.2 VM (modulo errors
            seen in regression test).
          • For the other canons (non-1.4.2 VMs), I have inserted the expected
            results, but not verified them.
          • I noticed the canon of phaseTester also contain metadata_test
            output, but I did not update this test's canon, as I am not familiar
            with how it should be updated. I'd appreciate advice on that.
          Show
          Dag H. Wanvik added a comment - The patch, derby965-v1. {stat,diff} , corrects the server data to the correct values, retaining the encoding used on the server side. The new values (metadata_net.properties) now reflect the capabilities of the server+network client driver:: '1003,1007,1008;1004,1007;1005' i.e. decoded: TYPE_FORWARD_ONLY,CONCUR_READ_ONLY,CONCUR_UPDATABLE; TYPE_SCROLL_INSENSITIVE,CONCUR_READ_ONLY TYPE_SCROLL_SENSITIVE DERBY-775 (client SUR) will be adding CONCUR_UPDATABLE to the second line later. The client's parsing and decoding has been changed to comply with this encoding style and now gives the correct result (changes in getMetaDataInfoInt_SupportsResultSetConcurrency). This patch should not give upgrade problems, in that an older client against a new server will give the same (wrong) results as before when trying to interpret type as concurrency. A new client against and old server will work, but give wrong results, although wrong in a different way from before. cf. the analysis of feb-13 above. Presumably, apps relying on this method would have failed always, so the changed result should not be too serious. Tests of this method has been added to metadata_test.java and embedded and derby network client canons have been updated. NOTE: Unfortunately, derbynetmats running the JCC client seems to have the same problem (it returns false for all type, concurrency combinations), so I had to make derbynetmats skip these new tests for that driver. derbyall has been run successfully on Sun's 1.4.2 VM (modulo errors seen in regression test). For the other canons (non-1.4.2 VMs), I have inserted the expected results, but not verified them. I noticed the canon of phaseTester also contain metadata_test output, but I did not update this test's canon, as I am not familiar with how it should be updated. I'd appreciate advice on that.
          Hide
          Dag H. Wanvik added a comment -

          The client gets metadata information form the server via a call to a
          stored procedure, SYSIBM.METADATA. In this case, column no 97 contains
          the information (for upportsResultSetConcurrency). This information is
          initialized in the dictionary from the file metadata_net.properties,
          which contains the following string value for column 97:

          '1003,1008;1004,1008;1005,1007,1008'

          which is an encoding of the allowable combinations of result set type
          and concurrency.

          There seems to be two problems here:

          1. The following comment block in the client explains
          its view of this encoding syntax:

          // The stored procured will return a String containg a list of
          // concurrency and list of resultSet types which support a perticular
          // concurrency For eg. if the database supports concurrency
          // CONCUR_READ_ONLY(1007) in ResultSet type TYPE_FORWARD_ONLY(1003),
          // TYPE_SCROLL_INSENSITIVE(1004), TYPE_SCROLL_SENSITIVE(1005) and
          // supports concurrency CONCUR_UPDATBLE(1008) in resultSet
          // TYPE_SCROLL_SENSITIVE(1005) then stored procedure will return a
          // string "1007,1003,1004,1005;1008,1005" see how concurrency and
          // supported result set types are seperated by ";"

          Unfortunately, the actual data seems to be the other way around,
          that is, for a given type, it lists the allowed concurrencies:

          '1003,1008;1004,1008;1005,1007,1008'

          which, when decoded becomes:

          TYPE_FORWARD_ONLY,CONCUR_UPDATABLE;\
          TYPE_SCROLL_INSENSITIVE,CONCUR_UPDATABLE;\
          TYPE_SCROLL_SENSITIVE,CONCUR_READ_ONLY,CONCUR_UPDATABLE

          In addition to being encoded differently, this is also wrong, in
          that Derby does not support scroll sensitive at all, whereas we
          do support CONCUR_READ_ONLY for the two other types (not given).

          Since the client checks for concurrency type against the first
          token of each substring, it will not get a match and always return
          false.

          2. The client code (even if given the expected syntax) has a coding
          bug:

          java.util.StringTokenizer st = new java.util.StringTokenizer(returnedFromSP, ";");
          while (st.hasMoreTokens()) {
          java.util.StringTokenizer stForType = new java.util.StringTokenizer(st.nextToken(), ",");
          if ((new Integer(stForType.nextToken())).intValue() == concurrency) {

            • while (st.hasMoreTokens()) {
            • if ((new Integer(st.nextToken())).intValue() == type) { return true; }

              }
              return false;
              }
              }
              return false;

          The inner loop uses the wrong tokenizer (st in stead of stForType)
          and will fail.

          So, we need to decide which encoding syntax is the correct one,
          correct the server's data and also fix the client bug. Note that this
          raises an upgrade issue, in that the existing client would crash if
          the server's data were corrected to the encoding syntax the client
          expects (due to the coding bug).

          Show
          Dag H. Wanvik added a comment - The client gets metadata information form the server via a call to a stored procedure, SYSIBM.METADATA. In this case, column no 97 contains the information (for upportsResultSetConcurrency). This information is initialized in the dictionary from the file metadata_net.properties, which contains the following string value for column 97: '1003,1008;1004,1008;1005,1007,1008' which is an encoding of the allowable combinations of result set type and concurrency. There seems to be two problems here: 1. The following comment block in the client explains its view of this encoding syntax: // The stored procured will return a String containg a list of // concurrency and list of resultSet types which support a perticular // concurrency For eg. if the database supports concurrency // CONCUR_READ_ONLY(1007) in ResultSet type TYPE_FORWARD_ONLY(1003), // TYPE_SCROLL_INSENSITIVE(1004), TYPE_SCROLL_SENSITIVE(1005) and // supports concurrency CONCUR_UPDATBLE(1008) in resultSet // TYPE_SCROLL_SENSITIVE(1005) then stored procedure will return a // string "1007,1003,1004,1005;1008,1005" see how concurrency and // supported result set types are seperated by ";" Unfortunately, the actual data seems to be the other way around, that is, for a given type, it lists the allowed concurrencies: '1003,1008;1004,1008;1005,1007,1008' which, when decoded becomes: TYPE_FORWARD_ONLY,CONCUR_UPDATABLE;\ TYPE_SCROLL_INSENSITIVE,CONCUR_UPDATABLE;\ TYPE_SCROLL_SENSITIVE,CONCUR_READ_ONLY,CONCUR_UPDATABLE In addition to being encoded differently, this is also wrong, in that Derby does not support scroll sensitive at all, whereas we do support CONCUR_READ_ONLY for the two other types (not given). Since the client checks for concurrency type against the first token of each substring, it will not get a match and always return false. 2. The client code (even if given the expected syntax) has a coding bug: java.util.StringTokenizer st = new java.util.StringTokenizer(returnedFromSP, ";"); while (st.hasMoreTokens()) { java.util.StringTokenizer stForType = new java.util.StringTokenizer(st.nextToken(), ","); if ((new Integer(stForType.nextToken())).intValue() == concurrency) { while (st.hasMoreTokens()) { if ((new Integer(st.nextToken())).intValue() == type) { return true; } } return false; } } return false; The inner loop uses the wrong tokenizer (st in stead of stForType) and will fail. So, we need to decide which encoding syntax is the correct one, correct the server's data and also fix the client bug. Note that this raises an upgrade issue, in that the existing client would crash if the server's data were corrected to the encoding syntax the client expects (due to the coding bug).
          Hide
          Dag H. Wanvik added a comment -

          Repro program (self contained).

          Show
          Dag H. Wanvik added a comment - Repro program (self contained).

            People

            • Assignee:
              Dag H. Wanvik
              Reporter:
              Dag H. Wanvik
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development