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