[ http://issues.apache.org/jira/browse/DERBY-1196?page=comments#action_12374197 ]
A B commented on DERBY-1196: ---------------------------- > Do you know what direct DB API means? No, I do not... > I am curious what the original exception was. It was a divide-by-zero exception. > It seems like the best course of action is to get an embedded repro for the > ASSERTION. Okay, I will see if I can do that based on your 2-step scenario (thanks for breaking it down). > 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. So given that the exception is a divide-by-zero error, which behavior would seem like the correct one? For the record, the behavior I see when I remove the ASSERTs matches at least one version of DB2 server--that doesn't necessarily mean it's right, but it does suggest that just closing the result set is a viable option, as opposed to throwing the error. I'll try to get an embedded reproduction and will post the results. Thanks for the feedback. > 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
