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: neutral (hermes.apache.org: local policy)
Message-ID: <42764BF4.8080509@sbcglobal.net>
Date: Mon, 02 May 2005 08:49:08 -0700
From: Jack Klebanoff <klebanoff-derby@sbcglobal.net>
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
MIME-Version: 1.0
To: Derby Development <derby-dev@db.apache.org>
Subject: Re: [jira] Updated: (DERBY-243) connection toString should uniquely
 identify the connection
References: <1417326426.1114706960485.JavaMail.jira@ajax.apache.org>
 <4272BB12.8000107@sun.com> <4272BC2B.5010601@sun.com>
 <4272C52C.5050506@sbcglobal.net> <4272D033.2060802@sun.com>
In-Reply-To: <4272D033.2060802@sun.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

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