db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dag H. Wanvik (JIRA)" <derby-...@db.apache.org>
Subject [jira] Commented: (DERBY-965) DatabaseMetadata method supportsResultSetConcurrency returns wrong result on network client
Date Mon, 13 Feb 2006 17:07:58 GMT
    [ http://issues.apache.org/jira/browse/DERBY-965?page=comments#action_12366214 ] 

Dag H. Wanvik commented on DERBY-965:
-------------------------------------

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).


> DatabaseMetadata method supportsResultSetConcurrency returns wrong result on network
client
> -------------------------------------------------------------------------------------------
>
>          Key: DERBY-965
>          URL: http://issues.apache.org/jira/browse/DERBY-965
>      Project: Derby
>         Type: Bug
>   Components: Network Client
>     Versions: 10.2.0.0
>  Environment: Solaris 10, x86, Sun JDK 1.4.2
>     Reporter: Dag H. Wanvik
>     Priority: Minor
>  Attachments: Main.java
>
> 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.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


Mime
View raw message