[
https://issues.apache.org/jira/browse/DERBY-3304?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12566033#action_12566033
]
Mamta A. Satoor commented on DERBY-3304:
----------------------------------------
The commit comments for 618788 did not include the bit about why I added
following to GenericLanguageConnectionContext.resetActivations
a.clearHeapConglomerateController();
if (!a.isSingleExecution())
a.clearWarnings();
Because of this, I (Andrew changed it for me since I kept getting errors while
using svn propedit --revprop -r 618788 svn:log) changed the commit comments for
618788 to read as follows
*************************start of new commit comments associated with revision
618788*****************************
This commit addresses two issues.
First of all, it cleanups up reset method in BaseActivation which was doing
more than just bringing the Activation back to pre-execution state. The method
had to make itself aware of holdability and what kind of resultset it was
dealing with before closing or clearing the row of the resultset. The reason
for this behavior is commit code path was relying on Activation.reset to do
more than just bringing the activation to pre-execution state. I fixed this by
moving this code from BaseActivation.reset to
GenericLanguageConnectionContext.resetActivations.
Additionally, in the new code in
GenericLanguageConnectionContext.resetActivations, I added the code to not
close the language result sets associated with activations that do not return
rows even if activation may have holdability set to false. This will ensure
that a commit inside a java procedure will not inadvertantly close the
resultset associated with the java procedure call. Additionally, I copied some
of the cleanup work(as shown below) from BaseActivation.reset into new code in
GenericLanguageConnectionContext.resetActivations
a.clearHeapConglomerateController();
if (!a.isSingleExecution())
a.clearWarnings();
This code above was always getting executed at the time of commit before my
commit and because of that, I decided to copy it in
GenericLanguageConnectionContext.resetActivations. If anyone has any comments
on this, please let me know.
*************************end of new commit comments associated with revision
618788*****************************
> 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.
