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