db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "A B (JIRA)" <derby-...@db.apache.org>
Subject [jira] Commented: (DERBY-1196) Network server closes prepared statements prematurely if exception occurs during OPNQRY and can cause "'Statement' already closed" exception on reexecution
Date Wed, 12 Apr 2006 00:19:21 GMT
    [ http://issues.apache.org/jira/browse/DERBY-1196?page=comments#action_12374119 ] 

A B commented on DERBY-1196:
----------------------------

The checkin for this issue is causing a new failure in the ODBC tests that I've been running--but
I'm not sure if it's a "regression" or not.  Please keep reading for more details.

The ODBC test that is seeing the failure is attempting to execute a SELECT query with 5 sets
of parameters in a batch-like fashion, where the middle set fails with an execution-time error.
 Prior to the fix for this issue the ODBC client could retrieve the 1st and 2nd result sets,
would see an "invalid cursor state" for the 3rd result set, and then attempts to retrieve
the 4th and 5th result sets would result in a "statement is already closed" error.  After
the fix, though, that same situation leads to an ASSERT failure in the Derby engine:

org.apache.derby.shared.common.sanity.AssertFailure: ASSERT FAILED ProjectRestrictResultSet
already open
	at org.apache.derby.shared.common.sanity.SanityManager.ASSERT(SanityManager.java(Compiled
Code))
	at org.apache.derby.impl.sql.execute.ProjectRestrictResultSet.openCore(ProjectRestrictResultSet.java:154)
	at org.apache.derby.impl.sql.execute.SortResultSet.openCore(SortResultSet.java:251)
...

I wrote code to try to do the same thing using the PreparedStatement.addBatch() functionality
with the Java clients, but both the Derby Client and the JCC client  throw client-side errors
saying: "Batching of queries not allowed by J2EE compliance."  Derby embedded fails as well,
but with an error saying "Statement.executeUpdate() cannot be called with a statement that
returns a ResultSet."

It appears that, somehow, the ODBC client is able to get this batch-like behavior to work
with the Network Server, even though there doesn't appear to be a way to do it from Java.
 Or at least that's true based on my own little experiments: namely, if I remove the execution-time
error from the above scenario, the server will correctly execute all five queries and return
5 result sets, which the ODBC client can then retrieve and process as normal using the ODBC
equivalent to "getMoreResults()" and "getResultSet()".

So I'm wondering if this constitutes a regression or not?  The apparent regressed behavior
is not visible from Java because both clients (and Derby embedded) disallow the operation.
 But the behavior does appear to have "regressed" for ODBC clients that allow batch-like execution
of SELECT queries.  Of course, I'm not sure what the ODBC behavior is supposed to be in the
case of a failed query--with DB2, the failed query simply won't return a result set, so only
4 result sets will be returned to the client.  Derby Network Server has never matched that
behavior--before the fix for this issue we returned 2 result sets and then closed the prepared
statement; after the fix we return 2 result sets and then fail with an assert.

So in short: is this a case of regressed behavior, or a case of functionality that has never
technically worked (at least not correctly) failing in a different way?  If it's not a regression,
then what's the best way to address this?

> Network server closes  prepared statements  prematurely if  exception occurs during OPNQRY
 and can cause "'Statement' already closed" exception on reexecution
> ---------------------------------------------------------------------------------------------------------------------------------------------------------------
>
>          Key: DERBY-1196
>          URL: http://issues.apache.org/jira/browse/DERBY-1196
>      Project: Derby
>         Type: Bug

>   Components: Network Server
>     Versions: 10.2.0.0
>     Reporter: Kathey Marsden
>     Assignee: Kathey Marsden
>     Priority: Minor
>      Fix For: 10.2.0.0

>
> There is a bug in  Network Server that it closes prepared statements if
> an error occurs during execution on OPNQRY (usually PreparedStatement.execute())
> Basically the problem is this code in DRDAConnThread.java
> processCommands() which catches any exception that occurs during  OPNQRY
> and closes the prepared statement .  OPNQRY is just the statement execution and any statement
level exceptions should not cause the statement to be closed.
> catch (SQLException e)
>                     {
>                         writer.clearDSSesBackToMark(writerMark);
>                         try {
>                             // Try to cleanup if we hit an error.
>                             if (ps != null)
>                                 ps.close();
>                             writeOPNQFLRM(e);
>                         }
>                         catch (SQLException pse) {}
>                         errorInChain(e);
>                     }
> There are cases in jdbcapi/setTransactionIsolation when run with JCC that trigger this
case and yield a 
> 'Statement' already closed message. 
> This was the core issue with DERBY-1047 but there were problems with the DERBY-1047 Jira
entry in that the description of the problem was wrong and also the issue itself no longer
occurs with the fix for DERBY-1158.
> DERBY-1047 will be closed invalid and this issue will be used to  track  the fix.

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