db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jack Klebanoff <klebanoff-de...@sbcglobal.net>
Subject Re: [jira] Updated: (DERBY-243) connection toString should uniquely identify the connection
Date Fri, 29 Apr 2005 23:37:16 GMT
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