[
https://issues.apache.org/jira/browse/DERBY-3581?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kristian Waagan updated DERBY-3581:
-----------------------------------
Derby Info: [Patch Available]
> Changing certain properties on client DataSource objects causes existing
> connections to reflect the new values
> --------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-3581
> URL: https://issues.apache.org/jira/browse/DERBY-3581
> Project: Derby
> Issue Type: Bug
> Components: JDBC, Network Client
> Affects Versions: 10.3.2.1, 10.4.0.0, 10.5.0.0
> Reporter: Kristian Waagan
> Assignee: Kristian Waagan
> Attachments: derby-3581-1a-remove_user_password_iteration1.diff
>
>
> The client driver has code propagating changes made to the DataSource to
> existing connections created by that DataSource.
> There is some discussion of this in the thread
> http://www.nabble.com/ConnectionPoolDataSource-properties-td15740457.html,
> and there is also an example of what can happen due to this "feature".
> Besides from being a bug with the potential to cause strange errors in
> deployment, the issue also makes the client driver code harder to read and
> understand.
> As far as I can see, there is also some related code in other parts of the
> client driver, for instance for "fully" resetting statements. There is
> mention of dynamic versus static sections in the comments (this one from
> am.Statement):
> // If a dataSource is passed into resetClientConnection(), then we will
> assume
> // properties on the dataSource may have changed, and we will need to go
> through
> // the open-statement list on the connection and do a full reset on all
> statements,
> // including preparedStatement's and callableStatement's. This is
> because property
> // change may influence the section we allocate for the
> preparedStatement, and
> // also the cursor attributes, i.e. setCursorSensitivity().
> // If no dataSource is passed into resetClientConnection(), then we will
> do the
> // minimum reset required for preparedStatement's and callableStatement's.
> Note that the reset code for statements is also invoked when
> ClientPooledConnection.getConnection() is invoked. I do not understand why we
> should reset statements when we get a new logical connection.
> Further, I also suspect the concept of a deferred reset has been introduced
> because of the feature/bug described by this Jira issue. A deferred reset
> seems to be a mechanism to avoid a round-trip to validate the newly changed
> DataSource properties (typically user, password and security mechanism).
> I will look into removing code related to deferred resets as well. If you
> have historic information about these parts of the driver, I would appreciate
> if you share it with the community if possible.
> Just to be clear, it is my opinion that changed DataSource properties should
> take effect when one of the following methods is invoked:
> * DataSource.getConnection()
> * ConnectionPoolDataSource.getPooledConnection()
> * XADataSource.getXAConnection()
> All of the methods above returns a physical connection. Properties like user
> name and password are associated with the physical connection, and thus
> requests to obtain a logical connection should not cause any of these
> properties to change.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
