db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel John Debrunner <...@debrunners.com>
Subject Re: [jira] Updated: (DERBY-243) connection toString should uniquely identify the connection
Date Fri, 06 May 2005 22:51:04 GMT
David Van Couvering (JIRA) wrote:

>      [ http://issues.apache.org/jira/browse/DERBY-243?page=all ]
> David Van Couvering updated DERBY-243:
> --------------------------------------
>     Attachment: DERBY-243.diff
> I am attaching the patch that should resolve this bug.  I added toString() to the
> appropriate connection classes and updated the dataSourcePermissions.java and 
> dataSourcePermissions_net.java tests to test toString().  I mostly just verify
> that two connections do not have the same string and follow the expected 
> pattern.  I had to "sed" out the actual connection ids in the output so we
> could guarantee a pass even if the ids change.

I'd like to see some crisper definition around what the return from
toString() is meant to represent for a connection.

- with this implementation, two different application connections from
the same PooledConnection end up with the same toString() output,
because the toString() of the underlying connection is used.

- however, a connection returned by jdbc:default:connection, has a
different toString() output to its parent connection.

That seems to be somewhat conflicting behaviour.

- do we want the class name in the output? I would say no.

I would like to see that at some point the return from toString() could
be used to correlate the connection with information from a diagnostic
table (vti). For example the value of PreparedStatement.toString()
corresponds to the identifier column of the statement cache vti.
This then could be used in diagnostics to show something like all locks
for this connection.


View raw message