[
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
