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 Wed, 11 May 2005 19:49:35 GMT


Daniel John Debrunner wrote:

> David Van Couvering wrote:
> 
> 
>>I haven't heard any responses on this, so I am going to make the
>>following changes/actions.  Speak now or... speak later, I guess :)
>>
>>- Use UUID to generate a unique id.  On the engine side I will use the
>>UUID service; on the client side I will use BasicUUID hardcoded.
> 
> 
> Sounds fine, but what still is the uniqueness of the string in just the
> *simple* cases, never mind the multiple class loaders, multiple jvms etc?

Apologies if I wasn't clear about this.  In my previous email, I argued 
that even in a "simple" case such as the network client, you can 
regularly be running in multiple classloaders (e.g. when Derby is 
running in an app server container).  So, rather than make this a 
configurable option where users have to figure out when they need use 
UUIDs, I was just going to use UUID all the time.

> 
> - Connections returned from jdbc:default:connection?
>   Unique string or string of parent connection?

I'm not sure what you mean by "parent connection.".  Is this a 
class-hierarchy relationship or some other kind of relationship?  Each 
physical connection should have its own unique connection string.  If it 
is a subclass of another connection class, it will inherit the code to 
obtain a connection id, but the instance will have its own independent 
string.

> 
> - subsequent application connections returned from
> PooledConnection.getConnection() - Unique I hope.

Well, I discussed this in my previous email, and argued that a 
NetConnection or EmbedConnection (which is what is returned from 
PooledConnection.getConnection()) should have a single id that lasts the 
lifetime of the instance.  If two separate transacations in separate 
threads get the same underlying EmbedConnection or NetConnection from a 
PooledConnection, then they will have the same id.  This actually seemed 
good -- it's more accurate and does not hide the reality of connection 
pooling.

In summary, each physical connection should have its own unique 
connection id, regardless of how it is obtained by the application.

The alternative is to "regenerate" a new id each time a connection is 
pulled off of the pool, but this seemed to create a concept of a 
"virtual" connection that only lasts the lifetime of a transaction. 
This just doesn't seem right...

David

> 
> Dan.
> 
> 
> 

Mime
View raw message