[
https://issues.apache.org/jira/browse/DERBY-3581?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kristian Waagan updated DERBY-3581:
-----------------------------------
Attachment: derby-3581-2a-remove_datasource_iteration1.diff
'derby-3581-2a-remove_datasource_iteration1.diff' removes the usage of the data
source when the connection is reset. The reset still happens when a new logical
connection is obtained, so this change would only affect pooled and xa
connections.
Further, since the reset method is only ever called with the
recomputeFromDataSource variable set to true, I plan to simplify the methods
and remove that variable.
Patch ready for review.
J2EEDataSourceTest, XATest and XATransactionTest ran cleanly. I'm running full
regression tests.
> 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,
> derby-3581-2a-remove_datasource_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.
