[ https://issues.apache.org/jira/browse/DERBY-3304?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12565471#action_12565471 ]
Daniel John Debrunner commented on DERBY-3304: ---------------------------------------------- I think the issue with the statistics is that functionality is being implemented in the incorrect location. Activation.reset() states that its role is to reset the activation for future executions. Using Activation.reset() to implement closing open JDBC result sets on a commit() just seems the wrong approach. Having an explicit method for commit that performed the close of a result set as required would be cleaner. Then Activation.reset() could have a clear purpose. Longer term the fix to DERBY-2485 would address this as then a result set that needed to be closed upon commit would simply register itself with the transaction manager such that it received notification of a commit. > Explicit commit inside a java procedure makes a dynamic result sets passed > out unavailable > ------------------------------------------------------------------------------------------ > > Key: DERBY-3304 > URL: https://issues.apache.org/jira/browse/DERBY-3304 > Project: Derby > Issue Type: Bug > Components: JDBC > Affects Versions: 10.4.0.0 > Reporter: Daniel John Debrunner > Assignee: Mamta A. Satoor > Attachments: Main.java > > > Repro (Main.java) that shows changed behavior after svn 602991 > (the patch committed for this issue). It seems a regression: (originally from > Dag H. Wanvik attached to DERBY-1585) > An explicit commit inside a stored procedure makes a dynamic result sets > passed out unavailable, even if the commit is executed *prior* to the result > set; as in the repro. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.