svn commit: r378552 - in /db/derby/code/trunk/java: drda/org/apache/derby/impl/drda/DRDAResultSet.java testing/org/apache/derbyTesting/functionTests/tests/derbynet/prepStmt.java

[km...@apache.org]

Author: kmarsden
Date: Fri Feb 17 07:59:55 2006
New Revision: 378552

URL: http://svn.apache.org/viewcvs?rev=378552&view=rev
Log:
DERBY-614 patch 2 - clear splitQRYTDA field for reuse of the resultset
Bryan said ..

 With my first patch to this bug, I introduced a problem in this processing; the
splitQRYDTA field was not cleared when the statement was closed. This meant that
if that splitQRYDTA field just happened to have some pending query data from the
previous statement at the point where it was re-used, the pending query data would
erroneously stick around and be returned as the first result for the new statement.

Contributed by Bryan Pendleton


Modified:
    db/derby/code/trunk/java/drda/org/apache/derby/impl/drda/DRDAResultSet.java
    db/derby/code/trunk/java/testing/org/apache/derbyTesting/functionTests/tests/derbynet/prepStmt.java

Modified: db/derby/code/trunk/java/drda/org/apache/derby/impl/drda/DRDAResultSet.java
URL: http://svn.apache.org/viewcvs/db/derby/code/trunk/java/drda/org/apache/derby/impl/drda/DRDAResultSet.java?rev=378552&r1=378551&r2=378552&view=diff
==============================================================================
--- db/derby/code/trunk/java/drda/org/apache/derby/impl/drda/DRDAResultSet.java (original)
+++ db/derby/code/trunk/java/drda/org/apache/derby/impl/drda/DRDAResultSet.java Fri Feb 17 07:59:55 2006
@@ -359,6 +359,7 @@
 		rsPrecision = null;
 		rsScale = null;
 		extDtaObjects = null;
+		splitQRYDTA = null;
 		rsExtPositions = null;
 		state=NOT_OPENED;
 		hasdata = true;

Modified: db/derby/code/trunk/java/testing/org/apache/derbyTesting/functionTests/tests/derbynet/prepStmt.java
URL: http://svn.apache.org/viewcvs/db/derby/code/trunk/java/testing/org/apache/derbyTesting/functionTests/tests/derbynet/prepStmt.java?rev=378552&r1=378551&r2=378552&view=diff
==============================================================================
--- db/derby/code/trunk/java/testing/org/apache/derbyTesting/functionTests/tests/derbynet/prepStmt.java (original)
+++ db/derby/code/trunk/java/testing/org/apache/derbyTesting/functionTests/tests/derbynet/prepStmt.java Fri Feb 17 07:59:55 2006
@@ -47,7 +47,7 @@
     private static String[] testObjects =  // string array for cleaning up
         {"table t1", "table tab1", "table t2", "table bigtab", "table tstab",
          "table doubletab", "table numtab", "table Numeric_Tab", "table jira614", 
-	 "table jira125", 
+	 "table jira614_a", "table jira125", 
          "table jira125125125125125125125125125125125125125125125125125125125125125125125125125125125125125125125"};
 
 	public static void main (String args[])
@@ -311,6 +311,7 @@
 			test5130(conn);
 			test5172(conn);
 			jira614Test(conn);
+			jira614Test_a(conn);
 			jira170Test(conn);
 			jira125Test(conn);
 			conn.close();
@@ -748,6 +749,46 @@
 		    buf.append(c);
 	    return buf.toString();
     }
+	// Part two of the regression test for bug 614 verifies that the
+	// server-side statement state is cleaned up when a statement is
+	// re-used. Specifically, we set up a statement which has a non-null
+	// splitQRYDTA value, then we close that statement and re-use it for
+	// a totally unrelated query. If the splitQRYDTA wasn't cleaned up
+	// properly, it comes flooding back as the response to that unrelated
+	// query, causing a protocol parsing exception on the client.
+	private static void jira614Test_a(Connection conn)
+		throws Exception
+	{
+		// 1: set up a second table to use for an unrelated query:
+	    Statement stmt = conn.createStatement();
+		PreparedStatement ps ;
+	    try { stmt.execute("drop table jira614_a"); } catch (Throwable t) { }
+	    stmt.execute("create table jira614_a (c1 int)");
+	    ps = conn.prepareStatement("insert into jira614_a values (?)");
+	    for (int row = 1; row <= 5; row++)
+		{
+			ps.setInt(1, row);
+		    ps.executeUpdate();
+		}
+
+		// 2: get the first statement into a splitQRYDTA state:
+		ResultSet rs = stmt.executeQuery("select * from jira614");
+		int rowNum = 0;
+		while (rs.next())
+		{
+			rowNum++;
+			if (rowNum == 26)
+				break;
+		}
+		// 3: Now re-use the statement for some totally different purpose:
+		stmt.close();
+		stmt = conn.createStatement();
+		rs = stmt.executeQuery("select * from jira614_a");
+		while (rs.next());
+		ps.close();
+		rs.close();
+		stmt.close();
+	}
     // Jira-170 has to do with how the server handles re-synchronization of
     // the data stream when an enormous parameter value follows a failed
     // prepare statement. Note that it is deliberate here that we are preparing