Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Derby Development" <derby-dev@db.apache.org>
Received-SPF: neutral (hermes.apache.org: local policy)
Date: Tue, 17 May 2005 14:10:13 -0700
From: David Van Couvering <david@vancouvering.com>
Subject: Re: [jira] Updated: (DERBY-243) connection toString should uniquely
 identify the connection
In-reply-to: <428A2852.6070902@sbcglobal.net>
To: Derby Development <derby-dev@db.apache.org>
Message-id: <428A5DB5.5010900@vancouvering.com>
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii; format=flowed
Content-transfer-encoding: 7BIT
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6)
 Gecko/20040113
References: <1510467190.1116266232063.JavaMail.jira@ajax.apache.org>
 <428A2852.6070902@sbcglobal.net>


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 string.
>>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,

David

> 
> Thanks
> 
> Kathey
> 
> 
>