[
https://issues.apache.org/jira/browse/DERBY-3304?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12572131#action_12572131
]
Knut Anders Hatlen commented on DERBY-3304:
-------------------------------------------
I read through the commit log and found a couple of nits in commit
#629926:
I think this change in EmbedStatement could be simplified:
- if (lrs.isClosed)
- return null;
+ try {
+ //following will check if the JDBC ResultSet or the language
+ //ResultSet is closed. If yes, then it will throw an exception.
+ //So, the exception indicates that the ResultSet is closed and
+ //hence we should ignore it.
+ lrs.checkIfClosed("");
+ } catch (SQLException ex) {
+ return null;
+ }
EmbedResultSet.isClosed() does the same thing, I think, so the above
code could be written as "if (lrs.isClosed()) return null;", which
looks a bit clearer to me. (Note, it's the isClosed _method_, not the
field.)
In GenericLanguageConnectionContext.endTransactionActivationHandling()
I saw this change:
+ ResultSet activationResultSet = null;
+ boolean resultsetReturnsRows = false;
+ if (a.getResultSet() != null) {
+ activationResultSet = a.getResultSet();
+ resultsetReturnsRows =
activationResultSet.returnsRows();
+ }
There's no reason to initialize activationResultSet to null first and
modify it inside the if statement. Just set it to a.getResultSet()
when it is initialized. Perhaps this would be clearer:
final ResultSet activationResultSet = a.getResultSet();
final boolean resultsetReturnsRows =
(activationResultSet != null) && activationResultSet.returnsRows();
Also, since resultsetReturnsRows is always false when
activationResultSet is null, it's not necessary to check that
activationResultSet is not null before checking that
resultsetReturnsRows is true later in that method.
> 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.
