[ 
https://issues.apache.org/jira/browse/DERBY-3304?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12565901#action_12565901
 ] 

Mamta A. Satoor commented on DERBY-3304:
----------------------------------------

Committed changes into trunk with revision 618788. The commit comments were as 
follows

***********************************************
DERBY-3304

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

I ran the Junit tests and derbyall on my Windows XP machine with jdk1.6 and saw 
no new failures.

As part of my committing the changes for this jira entry, 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 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.



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

Reply via email to