db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Van Couvering <da...@vancouvering.com>
Subject Re: [jira] Updated: (DERBY-243) connection toString should uniquely identify the connection
Date Tue, 17 May 2005 21:10:13 GMT

Kathey Marsden wrote:
> David Van Couvering (JIRA) wrote:
>>I have replaced the old patch with this one.  This one uses UUID to identify a connection
>>It also provides independent connection strings for PooledConnection classes.  
> Hi David
> Just so I understand the connection id semantics as I review this patch,
> could you tell me whether the following statements are true or false
> with regard to your patch. Please specify if the behaviour is different
> for embedded and client.
> 1)  Each physical connection has its own unique connection id,
> regardless of how it is obtained by the application.

Yes, that's right

> 2) If a stored procedure is called from a connection with connection id
> X,  and the stored procedure obtains a connection with
> DriverManager.getConnection("jdbc:default:connection"),  the connection
> in the stored procedure will also have
>     connection id X.

Yes, that's right

> 3) Every logical connection obtained from a single pooled connection
> will  have the same connection id.

This should generally be the case, because BrokeredConnection.toString() 
and LogicalConnection.toString() delegate to their underlying physical 
connections, which are owned by one and only one pooled connection (as 
far as I can see).

However, if for some reason a pooled connection needs to associate 
itself with a new physical connection, there is nothing in the code I 
added that prevents this, and then you will get a new id when you call 
getConnection().  I couldn't see any code that exists that actually does 
this, but I didn't make any specific assumptions of a 1-1 correspondence 
between pooled connection and the underlying physical connection.



> Thanks
> Kathey

View raw message