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 Mon, 02 May 2005 17:24:31 GMT
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.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>
>>>
>>
> 

Mime
View raw message