db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kathey Marsden <kmarsdende...@sbcglobal.net>
Subject Re: [jira] Updated: (DERBY-243) connection toString should uniquely identify the connection
Date Thu, 12 May 2005 18:16:11 GMT
David Van Couvering wrote:

> To me, my itch around this item is debugging, I have had to do a lot
> of this in the field, and missing something like a unique identifer
> for a connection can be pretty serious in terms of time spent trying
> to track down a bug, especially if the bug only rears it head in
> specific production situations, or it has only happened once but the
> impact was severe.
Good!   I am glad you are making all this effort  for your own
gratification #:)

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

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.

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


View raw message