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

          Dag H. Wanvik created issue -
          Dag H. Wanvik made changes -
          Field Original Value New Value
          Attachment Main.java [ 12322923 ]
          Dag H. Wanvik made changes -
          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).
          ]
          Dag H. Wanvik made changes -
          Link This issue is part of DERBY-310 [ DERBY-310 ]
          Dag H. Wanvik made changes -
          Component/s Network Server [ 11410 ]
          Component/s Network Client [ 11690 ]
          Dag H. Wanvik made changes -
          Component/s Network Client [ 11690 ]
          Dag H. Wanvik made changes -
          Assignee Dag H. Wanvik [ dagw ]
          Dag H. Wanvik made changes -
          Attachment derby965-v1.stat [ 12323321 ]
          Attachment derby-992-1.diff [ 12323322 ]
          Dag H. Wanvik made changes -
          Other Info [Patch available]
          Dag H. Wanvik made changes -
          Attachment derby-992-1.diff [ 12323322 ]
          Dag H. Wanvik made changes -
          Attachment derby965-v1.diff [ 12323324 ]
          Dag H. Wanvik made changes -
          Attachment derby965-v2.diff [ 12323483 ]
          Attachment derby965-v2.stat [ 12323482 ]
          Dag H. Wanvik made changes -
          Fix Version/s 10.2.0.0 [ 11187 ]
          Dag H. Wanvik made changes -
          Attachment derby965-v3.diff [ 12323649 ]
          Attachment derby965-v3.stat [ 12323648 ]
          Dag H. Wanvik made changes -
          Comment [ This patch 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.
              ]
          Dag H. Wanvik made changes -
          Attachment derby965-v3.diff [ 12323649 ]
          Dag H. Wanvik made changes -
          Attachment derby965-v3.stat [ 12323648 ]
          Dag H. Wanvik made changes -
          Attachment derby965b-v1.stat [ 12323650 ]
          Attachment derby965b-v1.diff [ 12323651 ]
          Knut Anders Hatlen made changes -
          Status Open [ 1 ] Resolved [ 5 ]
          Resolution Fixed [ 1 ]
          Dag H. Wanvik made changes -
          Status Resolved [ 5 ] Closed [ 6 ]
          Dag H. Wanvik made changes -
          Link This issue relates to DERBY-1252 [ DERBY-1252 ]
          Gavin made changes -
          Workflow jira [ 12346983 ] Default workflow, editable Closed status [ 12797687 ]

            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