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 Tue, 10 May 2005 16:25:17 GMT

Kathey Marsden wrote:

> David Van Couvering wrote:
> 
> 
>>Hi, all.  I have had some further thought on this, and I have a
>>proposal.  It seems like how one generates ids depends upon the
>>environment Derby is running in.  In a single-VM environment, probably
>>the hashCode() solution is best because it works even if there are
>>multiple systems in the same VM.  However, in a clustered environment,
>>a UUID is probably required.  So I am proposing creating a new
>>service, ObjectIdGenerator.  This allows us to plug in a different
>>implementation at some future date if need be.
>>
> 
> 
> I have to admit  my feeble eyes are disappointed at the loss of the
> counter and I don't really get how you separate out some things like
> the  error logs in these multiple jvm systems , but any additional help
> in differentiating connections would be welcome so hashcodes, counters, 
> UUID's, all   fine with me.
> 

Yes, I agree, but it would be a real pain if you got the same id twice! 
And with hashCode, you can avoid the need for specifying the class name 
as part of the id, as hashCode is unique across classes.

>  I am assuming the ObjectIdGenerator is just  an engine side service? 
> Right now the only shared classes between the engine and client are the
> product version and sysinfo classes.  If classes that are likely to
> change get included in both jars it could be ugly and with mismatched
> clients and servers you would get different implementations depending on
> what came first in your classpath.

Hi, Kathey, you have a good point about the ObjectIdGenerator being 
shared.  I would like to understand our goal for sharing code across 
network client and server.  It sounds like right now there is no sharing 
and if you have similar functionality it must be duplicated.  Isn't 
there any way to fix this?  Could we have a derbyutils.jar or 
derbycore.jar or something like that which is shared between both client 
and server code, where common services like this can go?

Also, don't we have the need for pluggable services (security, logging, 
etc.) on the network client side?  Shouldn't we have some model like the 
server-side module/service model for the network client code?

In the meantime, I think what I'll do is just use the identityHashCode() 
for the network-client connection ids.  If and when we agree on an 
approach I can (or someone else can) adjust this in the future

> 
> 
> 
>>>Another thing that would be very nice is if, in client/server mode,
>>>client connection toString() has a correlation to the resulting
>>>embedded connection toString() created on the server side for that
>>>session.  This way you could get end-to-end correlation.
>>
> 
> This maybe could be done by fixing  Derby-17,   Network Server Needs to
> generate CRRTKN on ACCRDB if client does not send it. The protocol has a
> pretty specific format which  perhaps would be helpful for your embedded
> format as well except it does include the network address, so you would
> have to look at it more closely to see.
> 
> I'll add some comments to Derby-17 with some more information.

OK.  I'd like to suggest this is a separate item, and doesn't need to be 
resolved with this patch, do you agree?

Thanks,

David
> 
> What an adventure!  
> 
> Kathey
> 
> 

Mime
View raw message