db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Van Couvering <David.Vancouver...@Sun.COM>
Subject Re: [jira] Updated: (DERBY-243) connection toString should uniquely identify the connection
Date Thu, 12 May 2005 21:28:44 GMT
Hi, Kathey, some responses below...

Kathey Marsden wrote:

> David Van Couvering wrote:
>>So I have been motivated to do this "right."  I suspect using the
>>default toString would have been satisfactory, but the effort required
>>to do it "right" has been minimal once we figured out what "right" was.
> Did we figure that out yet?   
> Could you give a brief summary of what  your  UUID means to the user
> when they see it?
> Connection.toString() is  a pretty quick and dirty debugging technique. 
> If you call toString() to debug your connections  it would be nice if 
> the output made it obvious what it meant without going to a manual.   

The output is pretty straightforward, it tells you it is a connection 
and then prints out the UUID.  Here is an example:

Connection c013800d-0103-d219-2006-ffffe2f84f9d

I *did* notice that for a given run (I guess for the same VM instance), 
all but the first part of the UUID sequence are identical, for example, 
here is another connection in the same run

Connection 862e0071-0103-d219-2006-ffffe2f84f9d

This should make it easier to quickly identify a given connection when 
reading output.

> For more advanced debugging folks tend to use the derby.log and the
> ErrorLogVTI, so if this effort is to assist with advanced debugging,
> these  may be worth considering before connection toString() so that
> they can be hooked up in a meaningful way.

Yes, this was what Dan was talking about, that the VTIs should include a 
column with the connection string that allows you to quickly correlate 
more detailed information with a connection string you observed in your 
debug output.  I had proposed to make this a separate JIRA item.

> I  wanted to also mention that currently in the derby.log for network
> server, we currently log a DRDAID which is the correlation token that I
> mentioned in my earlier mail. This id is a combination of the network
> address and the time in milliseconds and is something that is currently
> generated by the client but really should be generated by the server
> (DERBY-17).  Just wanted to make sure that was considered in your
> connection identification solution.  Not unique but certainly useful in
> debugging as you can see where the connection is coming from.  And as
> you mentioned it would be nice to have that correlation between client
> and server, but it is not a UUID.  Something to consider when you
> evaluate the id's we already have, as well as the new one, and how they
> all fit into the debugging  picture.

I think it would be great to allow you to correlate a client and 
server-side connection.

I am suggesting we log this as a separate JIRA item, to avoid piling too 
much into DERBY-243, which only asks that connection toString() be unique.

One approach would be that the toString() of an embedded connection 
created for a network session includes the DRDAID.  However, I think 
that makes the string output too complicated.  An alternate approach is 
to create a Connection VTI which includes this information.

The same thing can be said for PooledConnections -- they have a 
relationship to an underlying physical connection.  But rather than clog 
up the toString() of PooledConnection with the id of the underlying 
physical connection, I would rather see the Connection VTI provide this 

> I know I said hashcodes, counters, UUID's or whatever, but I am
> beginning to reconsider that position.   If we are looking at the big 
> connection identification picture,  I would like to understand what we
> have, what  the overall goals are and how what you are doing fits in
> with the existing id's.   Too many id's can be as bad as not enough.

I am not fully sure I know what you mean by "what we have", but in terms 
of connections, IMHO what we have currently is not sufficient -- a 
mishmash of the default toString() output, "" (returned by 
BrokeredConnection) and "EmbedConnection" for embedded connections.

To me the overall goal is to support debugging in critical situations, 
which means to me providing a toString() representation that is unique 
across any supported or envisioned usage models.  Given that this 
includes running in multiple classloaders (and I think this not going to 
be uncommon), and after much discussion about unique identifiers, I am 
convinced the righth approach is to use UUID.

In terms of how this fits with existing ids, I think the main thing that 
needs to be addressed is what we discussed above: that relevant VTIs 
include a correlation back to the owning connection so useful queries 
can be run, and that we make it possible correlate an embedded 
connection with its matching client-side connection.  I think both of 
these are beyond the scope of DERBY-243 but are worth working on as 
separate items.

So, once we have a unique connection identifier as a basis, I think 
there is a lot of opportunity here to provide some very useful detailed 
debugging information.

>>I think there's value in a simple fix bringing up a larger issue for
>>discussion.  I agree that you don't want to try and *fix* these larger
>>issues as part of the initial bug, rather they should be added as new
>>feature requests or bugs.  But I think they are healthy discussions to
>>have and can improve the overall design and quality of the product.
> Yes, I agree, but  I do think that it is good  to start a new thread for
> new issues.  Someone interested in  a proposal on changing the jar files
> we distribute  might not think to look under the connection toString
> thread. A new thread also provides more clear separation between the
> original issue and the larger issue it raised.  There is a lot of mail
> !    You might be interested in the Jakarta project mail guidelines and
> associated links at: http://jakarta.apache.org/site/mail.html.

OK, thanks, that's valuable feedback.  I will definitely keep that in 
mind in the future.

What I can do in this instance is when I create separate JIRA items for 
the things beyond the scope of DERBY-243, I will include in the comments 
a link to this thread as well as a summary of what we discussed in this 


> Kathey

View raw message