db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kathey Marsden (JIRA)" <derby-...@db.apache.org>
Subject [jira] Commented: (DERBY-149) Server hang when invalid string is bound to datetime columns.
Date Wed, 21 Sep 2005 01:00:32 GMT
    [ http://issues.apache.org/jira/browse/DERBY-149?page=comments#action_12330055 ] 

Kathey Marsden commented on DERBY-149:
--------------------------------------

Looking at this problem, I see that other types of errors, such as insert of a null value
into a not null column seem to work ok. Looking at two types of errors in the trace,  I see
the following.

SUCCESSFUL ERROR PROCESSING (invalid insert of null value. handled ok)
[derby]        SEND BUFFER: EXCSQLSTT             
[derby]        SEND BUFFER: SQLDTA       
[derby]        SEND BUFFER: RDBCMM      
[derby]        RECEIVE BUFFER: SQLCARD (With error 23502)
[derby]        RECEIVE BUFFER: ENDUOWRM  
[derby]        RECEIVE BUFFER: SQLCARD   (null SQLCARD)


PROBLEM  ERROR PROCESSING (invalid conversion)

[derby]        SEND BUFFER: EXCSQLSTT  
[derby]        SEND BUFFER: SQLDTA   
[derby]        SEND BUFFER: RDBCMM  
[derby]        RECEIVE BUFFER: SQLCARD (Exception 22007)

In the  problem  case, the server never sends the ENDUOWRM and SQLCARD that it should. The
client blocks waiting for a response to its chained RDBCMM which the server never sent.

In the server, in parseSQLDTA on exception, we call skipRemainder(false) to skip the rest
of the DSS. The false parameter  means it will skip DSS's even if they have a different correlation
id, which means in this case it gets a little too skippy and skips the RDBCMM Command.

Changing the line to skipRemainder(true) fixes the problem and makes sense to me because the
DRDA manual seems to indicate that you should only get a new correlation identifier for a
new command (page 76).   

My specific question (at last)  is this:

Are there any situations where we might need to skip a DSS with a different correlation ID
 when parsing the parameters in parseSQLDTA?  


> Server hang when invalid string is bound to datetime columns.
> -------------------------------------------------------------
>
>          Key: DERBY-149
>          URL: http://issues.apache.org/jira/browse/DERBY-149
>      Project: Derby
>         Type: Bug
>   Components: Network Server
>  Environment: Derby running with Network Server via JDBC universal driver.
>     Reporter: A B
>     Assignee: Kathey Marsden

>
> When running against Derby Network Server with the JCC driver, attempts to bind an invalid
date/time string to a date/time/timestamp parameter lead to a hang in either the JCC client
or in the Network Server (not sure which).
> The problem does NOT occur if the same thing is run against a DB2 server, which suggests
the bug is in Network Server, not in the JCC driver.  That said, though, the problem also
does NOT happen if one uses an ODBC client to connect to Network Server, instead of a JDBC
client--so perhaps it's a problem with JCC, after all...hard to say one way or the other...
> Here's a simple program to reproduce the problem:
> import java.sql.*;
> public class go {
> 	public static void main (String[] args) throws Exception {
> 		Class.forName("com.ibm.db2.jcc.DB2Driver");
> 		Connection c = DriverManager.getConnection(
> 			"jdbc:derby:net://localhost:1527/ugh;create=true", "bah", "humbug");
> 		Statement s = c.createStatement();
> 		try {
> 			s.execute("drop table dt");
> 		} catch (SQLException se) {}
> 		s.execute("create table dt (d date)");
> 		PreparedStatement pSt = c.prepareStatement("insert into dt values (?)");
> 		try {
> 			pSt.setString(1, "oops"); // invalid date value.
> 			pSt.execute();
> 		} catch (SQLException se) {
> 			System.out.println("Got " + se.getSQLState() + ": " + se.getMessage());
> 		}
> 	}
> }
> Of course, in order for the program to run, one must start the Network Server on port
1527 first.

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