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-1434) Client can send incorrect database name to server after having made multiple connections to different databases.
Date Thu, 22 Jun 2006 03:21:30 GMT
    [ http://issues.apache.org/jira/browse/DERBY-1434?page=comments#action_12417238 ] 

Kathey Marsden commented on DERBY-1434:
---------------------------------------

A USER SYMPTOM

I see that if our table in the first database has more data than can be retrieved in one QRYDTA
 this can cause a  ResultSet to close prematurely if a query is executed against the second
database before  all results are fetched from the server.

TRIGGERING SCENARIO

I am working with a user database, and  don't have the case incorporated into Army's repro
, but  below is the general  code flow.

 PreparedStatement ps = conn1.prepareStatement(sql);
	
	  rs = ps.executeQuery();  // execute a query from db 1 that returns a lot of  data
	  // get some data
	  rs.next();
	  // now interject another statement.
	  // This will reuse the statement id (pkgnamcsn) from our old db and close it.
	  PreparedStatement ps2 = conn2.prepareStatement("Select count(*) from sys.systables");
	  ResultSet rs2 = ps.executeQuery();
	  rs2.next();
	  // now lets try to get the rest of the data from our first query.
		int rownum = 1;
		while(rs.next()){
               ....
		}


THE EXCEPTION

SQLException: org.apache.derby.client.am.SqlException: Invalid operation: result set closed
org.apache.derby.client.am.SqlException: Invalid operation: result set closed
        at org.apache.derby.client.am.ResultSet.checkForClosedResultSet(ResultSet.java:3287)
        at org.apache.derby.client.am.ResultSet.nextX(ResultSet.java:250)
        at org.apache.derby.client.am.ResultSet.next(ResultSet.java:240)


This occurs because  Network Server keys statements off of the PKGNAMCSCN which will be duplicated
by the client incorrectly  in this case.  
The relevant server side code is in: org.apache.derby.impl.drda.Database:
protected DRDAStatement newDRDAStatement(Pkgnamcsn pkgnamcsn)
	throws SQLException
	{
		DRDAStatement stmt = getDRDAStatement(pkgnamcsn);
		if (stmt != null) {
			stmt.close();
			stmt.reset();
		}
It closes the statement as soon as it gets the duplicate pkgnamcsn in.   Of course the problem
is that the client code sends a dup, not that the server closes when it sees a dup, but I
don't  know where that code is off the top of my head #:)





> Client can send incorrect database name to server after having made multiple connections
to different databases.
> ----------------------------------------------------------------------------------------------------------------
>
>          Key: DERBY-1434
>          URL: http://issues.apache.org/jira/browse/DERBY-1434
>      Project: Derby
>         Type: Bug

>   Components: Network Client
>     Versions: 10.1.2.5, 10.1.3.0, 10.2.0.0
>     Reporter: A B
>     Priority: Minor
>      Fix For: 10.2.0.0
>  Attachments: Server2.trace, _driver_1, d1434.java
>
> I have a simple program that connects to a database using the Derby Client, executes
a simple query, then connects to a different database using a different Connection object
and executes another simple query on that second connection.  The queries both execute without
error, so it appears that the connections are correct--i.e. each query will only work on one
of the databases, and both queries work, therefore each must be getting executed against the
correct database.
> But in looking at the client and server traces, I noticed that for the query on the second
database, the client is actually sending the name of the *first* database as RDBNAM, which
(I think?) is wrong--it should be sending the name of the second database, since the query
is being executed on the second Connection object.
> This behavior does not appear to occur for JCC.

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