[
http://issues.apache.org/jira/browse/DERBY-1196?page=comments#action_12374193 ]
Kathey Marsden commented on DERBY-1196:
---------------------------------------
It seems like there must be an embedded reproduction for the ASSERTION. From
the description it seems like:
1) The statement was executed (PreparedStatement.execute() )once and got some
exception.
This exception used result in the statement getting closed, but no longer
is that the case.
2) The statement gets executed a second time and gets this ASSERTION because
the result set is open
I am curious what the original exception was. It seems like the best course
of action is to get an embedded repro for the ASSERTION and then fix that bug.
It seems like either the embedded driver should have closed the result set with
the original exception or as the comment says, the exception that the result
set is still open should be a real error. We'd have to see what the original
exception was to know which is the case.
Kathey
> 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
