[
https://issues.apache.org/jira/browse/DERBY-3304?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12566040#action_12566040
]
Mamta A. Satoor commented on DERBY-3304:
----------------------------------------
Since we do not reset the activations at the time of commit, the name of the
method, resetActivations() in GenericLanguageConnectionContext is misleading. I
am not too creative with names but I am thinking of changing the name
resetActivations to activationRelatedCleanup. If anyone has any other
suggestion for the name change, please let me know.
In addition, i am changing the javadoc for resetActivations to reflect what it
is really doing. The new javadoc comments that I am planning to have are as
follows
/**
If we are called as part of rollback code path, then we will
reset all
the activations.
If we are called as part of commit code path, then we will do
one of
the following if the activation has resultset assoicated with it
1)Close result sets that return rows and are not held across
commit.
2)Clear the current row of the resultsets that return rows and
are
held across commit.
3)Leave the result sets untouched if they do not return rows
Additionally, clean up (close()) activations that have been
marked as unused during statement finalization.
@exception StandardException thrown on failure
*/
In addition, I am checking to see if following code can be removed from
resetActivations
/*
** andClose true means we are here for rollback.
** In case of rollback, we don't care for holding
** cursors and that's why I am resetting holdability
** to false for all activations just before rollback
*/
if (andClose)
a.setResultSetHoldability(false);
> 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.
