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

Knut Anders Hatlen commented on DERBY-3446:
-------------------------------------------

The patch looks fine to me. Two small questions:

Does ResultSet.creatingStatement have to be volatile? It seems like it's always 
set before the ResultSet is returned to the user, and not modified later, so I 
can't see that there are any threading/visibility issues even if it's not 
volatile.

Have you considered this alternative approach:
  - have a field called owner in am.Statement
  - in LogicalStatementEntity's constructor, cast physicalPS to 
am.PreparedStatement and set the owner
  - implement am.ResultSet.getStatement() as "if (statement_.owner != null) 
return statement_.owner; else return statement_;"

I may have overlooked something, but it sounds like this requires even fewer 
changes, and, more importantly, it's more robust as it will work automatically 
if more methods that return ResultSets are added to the JDBC interfaces later.

> Make ResultSet.getStatemet return the correct statement when created by a 
> logical statement
> -------------------------------------------------------------------------------------------
>
>                 Key: DERBY-3446
>                 URL: https://issues.apache.org/jira/browse/DERBY-3446
>             Project: Derby
>          Issue Type: Task
>          Components: JDBC, Network Client
>    Affects Versions: 10.4.0.0
>            Reporter: Kristian Waagan
>            Assignee: Kristian Waagan
>            Priority: Minor
>             Fix For: 10.4.0.0
>
>         Attachments: derby-3446-1a_rs_getstatement.diff, 
> derby-3446-1a_rs_getstatement.stat
>
>
> ResultSet.getStatement must return the correct statement, that is the 
> statement that created the result set.
> It is particularly important for result set created by logical statements, as 
> leaking of physical statements can cause all kinds of side effects in a 
> connection pooling environment.

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