[
https://issues.apache.org/jira/browse/DERBY-3304?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12566034#action_12566034
]
Mamta A. Satoor commented on DERBY-3304:
----------------------------------------
I need to admit that I do not completely understand why BaseActivation.reset()
has following code
updateHeapCC = null;
// REMIND: do we need to get them to stop input as well?
if (!isSingleExecution())
clearWarnings();
But since this piece of code was getting exectued for an activation at the time
of commit, I decided to copy similar code in
GenericLanguageConnectionContext.resetActivations since a commit code path now
is not going to goto BaseActivation.reset().
Would appreciate if someone knows more about this code and can share if this
piece of code is needed at the time of commit or not. I *quickly* looked at
JDBC Connection,commit api and did not see anything about clearing the warnings
at the time of commit. So, maybe we do not need to clear the warnings in
GenericLanguageConnectionContext.resetActivations when a commit is executed. I
am even more unclear about the purpose of a.clearHeapConglomerateController();
at the time of commit. But I copied it just to be on the safe side so that we
execute the same set of code as before my checkin.
Does anyone have any insight into whether or not this code is needed at commit
time?
> 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.
