Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Received-SPF: pass (athena.apache.org: local policy)
Date: Thu, 28 Feb 2008 20:20:36 +0100
From: Kristian Waagan <Kristian.Waagan@Sun.COM>
Subject: Re: ConnectionPoolDataSource properties
In-reply-to: <47C70779.8060501@apache.org>
Sender: Kristian.Waagan@Sun.COM
To: derby-dev@db.apache.org
Message-id: <47C70984.30501@Sun.com>
Organization: Sun Microsystems Inc.
MIME-version: 1.0
Content-type: text/plain; format=flowed; charset=ISO-8859-1
Content-transfer-encoding: 7BIT
References: <47C6E306.1060509@Sun.com> <47C6E60D.4010502@apache.org>
 <47C7014C.2020007@Sun.com> <47C70779.8060501@apache.org>
User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; no-NO;
 rv:1.8.1.9) Gecko/20071119
 Thunderbird/2.0.0.9 Mnenhy/0.7.5.0

Daniel John Debrunner wrote:
> Kristian Waagan wrote:
>> Daniel John Debrunner wrote:
> 
>>> A pooling implementation is holding onto PooledConnection objects and 
>>> has some rules for how a logical connection request map to a given 
>>> pool (e.g. database TEST to pool A). If when the PooledConnection was 
>>> created it pointed to database TEST, but now points to database 
>>> PRODUCTION I think that would be a major surprise to a pooling 
>>> implementation.
>>
>> I don't think it's that severe, but my observation does hold for some 
>> properties. As far as I can see, the following data source properties 
>> are definitely updated for a logical connection when 
>> ClientPooledConnection.getConnection() is called:
>>     - user
> 
> User name is severe, I was connecting as DAN but got switched to DBADMIN 
> :-).
> 
> Unlikely to occur in real applications, but the CPDS should not allow this.

Thanks for checking.
I'll log a JIRA issue tomorrow, maybe I gain some more insight until then.


-- 
Kristian

> 
> Dan.