[
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.
