Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Derby Development" <derby-dev@db.apache.org>
Received-SPF: pass (hermes.apache.org: local policy)
Date: Mon, 02 May 2005 16:07:21 -0700
From: David Van Couvering <David.Vancouvering@Sun.COM>
Subject: Re: [jira] Updated: (DERBY-243) connection toString should uniquely
 identify the connection
In-reply-to: <4276624F.1060903@sun.com>
To: Derby Development <derby-dev@db.apache.org>
Message-id: <4276B2A9.7040805@sun.com>
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii; format=flowed
Content-transfer-encoding: 7BIT
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6)
 Gecko/20040113
References: <1417326426.1114706960485.JavaMail.jira@ajax.apache.org>
 <4272BB12.8000107@sun.com> <4272BC2B.5010601@sun.com>
 <4272C52C.5050506@sbcglobal.net> <4272D033.2060802@sun.com>
 <42764BF4.8080509@sbcglobal.net> <4276624F.1060903@sun.com>

I'll take silence as consent?  I'll go ahead with a simple incrementing 
counter approach.

David

David Van Couvering wrote:

> Although I agree you don't want your debug code to bog down your 
> production code, when it is time to debug, your debug code is very 
> important.  When I am debugging a nasty contention issue, and I get two 
> connections with the exact same id, then that could be a REAL problem.
> 
> Also, I can imagine providing a getId() method on Connection that could 
> be used for other things within the system.  It would be nice if we 
> could guarantee uniqueness.
> 
> I agree that identityHashCode is probably fine.  But I think that a 
> basic incrementing counter is very simple to implement, and then we 
> could be assured of uniqueness.  I do notice that an incrementing 
> counter is already implemented in a number of other places in the code 
> already, so this wouldn't be a new thing.
> 
> However, I will be happy to go with identityHashCode if that is the 
> general consensus.
> 
> David
> 
> Jack Klebanoff wrote:
> 
>> If the Derby client absolutely requires that its Connection class 
>> toString methods return unique, that is if the client would fail to 
>> work if toString() were not unique, then we could toString could not 
>> use identityHashCode. However, I do not believe that this is the case. 
>> I think that uniqueness is very helpful but not required.
>>
>> It is true that identityHashCode is not guaranteed to be unique. 
>> However, in practice it almost always is unique.
>>
>> My understanding is that toString is used for debugging. I don't think 
>> that we should burden the production with debug code when we have 
>> simpler methods that, in practice if not in theory, will work just fine.
>>
>> Jack Klebanoff
>>
>> David Van Couvering wrote:
>>
>>> Hm, I always thought a hash-code was not unique.  I got excited when 
>>> you mentioned this method, identityHashCode(), which I hadn't heard 
>>> of, but it basically delegates to Object.hashCode(), it just ensures 
>>> that the hash code returned is the base Object hash code and not one 
>>> returned by an overriding method.
>>>
>>> The documentattion for hashCode() says
>>>
>>> "It is not required that if two objects are unequal according to the 
>>> equals(java.lang.Object) method, then calling the hashCode method on 
>>> each of the two objects must produce distinct integer results. 
>>> However, the programmer should be aware that producing distinct 
>>> integer results for unequal objects may improve the performance of 
>>> hashtables.
>>>
>>>  As much as is reasonably practical, the hashCode method defined by 
>>> class Object does return distinct integers for distinct objects. 
>>> (This is typically implemented by converting the internal address of 
>>> the object into an integer, but this implementation technique is not 
>>> required by the JavaTM programming language.)"
>>>
>>> So, we can depend on it *most* of the time, but that makes me a bit 
>>> nervous...
>>>
>>> David
>>>
>>> Jack Klebanoff wrote:
>>>
>>>> The simplest thing would be to use the 
>>>> java.lang.System.identityHashCode method on the connection object. I 
>>>> believe that it is unique in a 32 bit system. In practice it will 
>>>> almost always be unique in a 64 bit system.
>>>>
>>>> I don't think that the Monitor or UUIDFactory classes are available 
>>>> in the client.They are part of the Derby server.
>>>>
>>>> Jack Klebanoff
>>>> ||David Van Couvering wrote:
>>>>
>>>>> One thought I had about the UUID approach, after proposing it, is 
>>>>> that if you're trying to correlate connections and trace messages 
>>>>> and you have these huge long UUID strings, it can be a bit 
>>>>> challenging.
>>>>>
>>>>> If it were a simple static long that starts at 1 and increments 
>>>>> each time a new connection instance is created (yes, the increment 
>>>>> would have to be synchronized), then it would be much more 
>>>>> readable.  This would also be more portable to the client code, and 
>>>>> we wouldn't have to cut/paste the UUID class to the client packages...
>>>>>
>>>>> Any thoughts?
>>>>>
>>>>> Thanks,
>>>>>
>>>>> David
>>>>>
>>>>> David Van Couvering wrote:
>>>>>
>>>>>> Hi, Kathey.  Currently the connection classes don't appear to have 
>>>>>> a unique identifier that could be made available in toString().  
>>>>>> Do I take it you would like me to find an approach that generates 
>>>>>> one?
>>>>>>
>>>>>> I noticed Derby has a UUID service (very nice!).  Is it OK if I 
>>>>>> use that here to generate a UUID for the connection?  If I don't 
>>>>>> hear otherwise, I'll assume this approach is OK, e.g.
>>>>>>
>>>>>> public class EmbedConnection
>>>>>> {
>>>>>>   private UUID UUIDValue;
>>>>>>   private String UUIDString;
>>>>>>
>>>>>>   public EmbedConnection()
>>>>>>   {
>>>>>>     UUIDFactory uuidFactory = Monitor.getMonitor().getUUIDFactory();
>>>>>>     UUIDValue = uuidFactory.createUUID();
>>>>>>     UUIDString = this.getClass().getName() + ":" + 
>>>>>> UUIDValue.toString();
>>>>>>     ...
>>>>>>   }
>>>>>>
>>>>>>   public String toString()
>>>>>>   {
>>>>>>      UUIDString;
>>>>>>   }
>>>>>> }
>>>>>>
>>>>>> =====
>>>>>>
>>>>>> The connection classes I found are as follows.  Please let me know 
>>>>>> if I missed any.  An indented class implies it extends the 
>>>>>> unindented class above it.
>>>>>>
>>>>>> EMBEDDED (org.apache.derby.engine.*)
>>>>>>   BrokeredConnection (implements java.sql.Connection)
>>>>>>     BrokeredConnection30
>>>>>>   EmbedConnection (implements java.sql.Connection)
>>>>>>     EmbedConnection30
>>>>>>   EmbedPooledConnection (implements java.sql.PooledConnection)
>>>>>>     EmbedXAConnection
>>>>>>
>>>>>> CLIENT (org.apache.derby.client.*_
>>>>>>   Connection (abstract class, implements java.sql.Connection))
>>>>>>     NetConnection
>>>>>>       NetXAConnection
>>>>>>   ClientXAConnection (implements java.sql.XAConnection)
>>>>>>   ClientPooledConnection (implements java.sql.PooledConnection)
>>>>>>   LogicalConnection (implements java.sql.Connection)
>>>>>>
>>>>>>
>>>>>> On the client side, I first need to understand: is derbyclient.jar 
>>>>>> supposed to be standalone (meaning it can't depend upon things in 
>>>>>> derby.jar like the Monitor and the UUID class).  If so, I suppose 
>>>>>> I could cut/paste the BasicUUID class into the client packages for 
>>>>>> use on the client side (shiver).  Alternately we could have a 
>>>>>> derbyutils.jar that is shared between client and server (Big 
>>>>>> Change, not sure if I want to take that on).  Advice here would be 
>>>>>> most appreciated.
>>>>>>
>>>>>> Thanks,
>>>>>>
>>>>>> David
>>>>>>
>>>>>> Kathey Marsden (JIRA) wrote:
>>>>>>
>>>>>>>      [ http://issues.apache.org/jira/browse/DERBY-243?page=all ]
>>>>>>>
>>>>>>> Kathey Marsden updated DERBY-243:
>>>>>>> ---------------------------------
>>>>>>>
>>>>>>>         Summary: connection toString should uniquely identify the 
>>>>>>> connection  (was: connection toString doesn't give enough 
>>>>>>> information)
>>>>>>>     Description: The toString() on the Derby connection doesn't 
>>>>>>> print unique information.
>>>>>>> for example  System.out.println(conn) prints:
>>>>>>> EmbedConnection  in the case of derby embedded
>>>>>>>
>>>>>>> It would be great if the toString() method for connections could 
>>>>>>> be used to differentiate one connection from another.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>   was:
>>>>>>> The toString() on the Derby connection doesn't print unique 
>>>>>>> information.
>>>>>>> for example  System.out.println(conn) prints:
>>>>>>> EmbedConnection  in the case of derby embedded
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> I am not sure if XA Connections and Pooled Connections have the 
>>>>>>> same issue.  I didn't immediately see an override of the 
>>>>>>> toString() method in BrokeredConnection.java like there is for 
>>>>>>> EmbedConnection
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> connection toString should uniquely identify the connection
>>>>>>>> -----------------------------------------------------------
>>>>>>>>
>>>>>>>>         Key: DERBY-243
>>>>>>>>         URL: http://issues.apache.org/jira/browse/DERBY-243
>>>>>>>>     Project: Derby
>>>>>>>>        Type: Improvement
>>>>>>>>  Components: JDBC
>>>>>>>>    Reporter: Kathey Marsden
>>>>>>>>    Assignee: David Van Couvering
>>>>>>>>    Priority: Trivial
>>>>>>>>     Fix For: 10.0.2.1, 10.0.2.0, 10.0.2.2, 10.1.0.0
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> The toString() on the Derby connection doesn't print unique 
>>>>>>>> information.
>>>>>>>> for example  System.out.println(conn) prints:
>>>>>>>> EmbedConnection  in the case of derby embedded
>>>>>>>> It would be great if the toString() method for connections could 
>>>>>>>> be used to differentiate one connection from another.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>
>>>>
>>>
>>
>