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 Sat, 30 Apr 2005 00:17:04 GMT
Hm, well, I don't know this code very well, but as far as I can tell, 
the EmbedConnection has an associated EmbedConnectionContext which it 
creates when constructed, but this context has no unique identifier, nor 
does its superclass all the way up the context stack.

I did notice that when a client connects to the network server, there is 
code that creates a connection number by incrementing a variable in 
DB2jServerImpl (it's disconcerting that it's not synchronized), and that 
this number is passed to the Session object, and that Session appears to 
use this when outputting traces (but I was a bit lost by then).

But this is not the same as what Kathey is looking for.  Perhaps it 
could be found by EmbedConnection (I actually hope not, as that would 
indicate circular dependencies), but even so it would only be available 
for EmbedConnections that were created to service a session from a 
remote client.

Is there a preference to have the unique id to be in the 
ConnectionContext rather than in the Connection?  I don't fully 
understand the roles and responsibilities of Context vs. the object it 
"contextizes" :) so I'd appreciate the guidance.  My intuition says 
simplicity dictates it goes in the Connection, but let me know if I'm 
wrong...

I will note that in general the approach for generating unique ids 
appears to be incrementing variables rather than using UUID.  In my 
searches for the mysterious session id, I saw two instances of this

GenericLanguageConnectionFactory.getNextLCCInstanceNumber()

and

DB2jServerImpl.getNewConnNum()

this latter one is called whenever a new client thread is created, I am 
pretty sure this is Mike's "session id".

So, I am leaning towards the increment approach for generating a new 
connection id rather than using UUID, especially since it will work in 
the client code as well.

Thanks,

David

Mike Matrigali wrote:

> I am not sure where the following information is contained, but somehow
> the log statement text trace in a network server connection use to 
> associate a "session id" with a connection.  So derby.log statments
> would be tagged with this info.  This is what I always used
> to understand the path of a connection within the log (often people will
> use thread id which can work, but does not work if connection pooling
> is involved).  This did not provide any sort of unique id for a given
> network server, though I don't know if that is necessary.
> 
> Maybe someone knows if this info is available to the EmbedConnection
> class, maybe from the context manager?
> 
> 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