You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-dev@db.apache.org by "A B (JIRA)" <de...@db.apache.org> on 2006/04/12 02:19:21 UTC
[jira] Commented: (DERBY-1196) Network server closes prepared
statements prematurely if exception occurs during OPNQRY and can cause
"'Statement' already closed" exception on reexecution
[ 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