db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kristian Waagan (JIRA)" <j...@apache.org>
Subject [jira] Commented: (DERBY-3581) Changing certain properties on client DataSource objects causes existing connections to reflect the new values
Date Thu, 03 Apr 2008 16:46:25 GMT

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

Kristian Waagan commented on DERBY-3581:
----------------------------------------

In the issue description, I wrote the following:
----- Kristian wrote:
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. 
-----

After reading some sections in the DRDA spec, I think that statement is wrong.
Sending what is called the deferred reset sequence in the driver (EXCSAT, ACCSEC, SECCHK and
ACCRDB), is specified by the DRDA spec. It says the source server *can* send it if it wants
to reuse the connection for another application or transaction, but I haven't found a place
where it says it has to send it.
I thought about sending only SECCHK and ACCRDB to reduce the work, but this is not allowed
by the DRDA spec (but I think it is allowed by the network server).

My current conclusion is that the deferred reset code still has to be used and cannot be removed.
The code related to picking up changes in the data source can however still be removed.
Implementing an alternative "reset protocol" might be possible, but that would be 10.5 or
maybe even 11. I'm sure a more efficient scheme can be implemented, but it is not clear to
me what the solution space looks like bounded by the DRDA spec.

BTW; derbyall ran cleanly for the 1a patch.

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


Mime
View raw message