[
http://issues.apache.org/jira/browse/DERBY-1196?page=comments#action_12374120 ]
A B commented on DERBY-1196:
----------------------------
As a follow-up comment, for what it's worth, I commented out two places where
we have ASSERT checks (one in ProjectRestrictResultSet and one in
TableScanResultSet) and when I did, things actually worked quite well. Namely,
the ODBC client was able to fetch the 1st and 2nd result sets, then it received
an "invalid cursor state" for the 3rd result set, and finally was able to
retrieve the 4th and 5th result sets without a problem.
This means that if I was to run the ODBC tests against an insane build, the
queries would actually "work" in a manner of speaking.
The comments for the ASSERT check in ProjectRestrictNode say the following:
// REVISIT: through the direct DB API, this needs to be an
// error, not an ASSERT; users can open twice. Only through JDBC
// is access to open controlled and ensured valid.
if (SanityManager.DEBUG)
SanityManager.ASSERT( ! isOpen, "ProjectRestrictResultSet
already open");
Perhaps this part of the code has to be "revisited", as the comment says...?
I don't know if that's helpful or not; I'm just posting I've observed...
> 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
