[
https://issues.apache.org/jira/browse/DERBY-3304?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12557480#action_12557480
]
Daniel John Debrunner commented on DERBY-3304:
----------------------------------------------
Nice findings!
> Interestingly, CallStatementResultSet#close is called as part of
> CallStatementResultSet#open... Is this correct?
I think it is confusing. Language result sets that do not return rows tend to
do this because all of their work is performed in the open(), thus to free up
any resources their open() call also calls close(). Now since the close will
be called from some external source anyway, I think it would be cleaner if the
open-close cycle was driven from the outside and not from within the open.
>From what you have found, it looks like a CallStatementResultSet should
>always be held across commits, though since that logic is applied to result
>sets that return rows, I don't know what real effect it would have here.
> 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
> 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.
