ConnectionPoolDataSource properties

[Kristian Waagan <Kr...@Sun.COM>]

Hello,

 From looking at the client driver, I get the impression the following 
expectation is valid:

// Initial data source creation and configuration
...
// Get physical connection
PooledConnection pc = cpDs.getPooledConnection();
// Get logical connection
Connection con = pc.getConnection();
...
// Reconfigure data source
...
// Get a new *logical* connection
con = pc.getConnection();
// The new logical connection has the changes made to the data source.

I thought you had to get a new pooled connection for the changes to take 
effect.
Does anyone know?


I was also surprised to discover that the client driver re-prepares all 
open statements when you do PooledConnection.getConnection().
Has there been a statement pooling mechanism in place earlier?
Why aren't the statement just closed instead?



thanks,
-- 
Kristian


Here's a comment from am.Statement:
// If a dataSource is passed into resetClientConnection(), then we will 
assume
// properties on the dataSource may have changed, and we will need to go 
through
// the open-statement list on the connection and do a full reset on all 
statements,
// including preparedStatement's and callableStatement's.  This is 
because property
// change may influence the section we allocate for the 
preparedStatement, and
// also the cursor attributes, i.e. setCursorSensitivity().
// If no dataSource is passed into resetClientConnection(), then we will 
do the
// minimum reset required for preparedStatement's and callableStatement's.

KW: The method referred (resetClientConnection) does not exist anymore.

Re: ConnectionPoolDataSource properties

[Kristian Waagan <Kr...@Sun.COM>]

Kristian Waagan wrote:
> Daniel John Debrunner wrote:
>> Kristian Waagan wrote:
>>> Daniel John Debrunner wrote:
>>
[ snip - issue description ]
> 
> Thanks for checking.
> I'll log a JIRA issue tomorrow, maybe I gain some more insight until then.

I have logged DERBY-3581 for this.
https://issues.apache.org/jira/browse/DERBY-3581


-- 
Kristian

Re: ConnectionPoolDataSource properties

[Kristian Waagan <Kr...@Sun.COM>]

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.

Re: ConnectionPoolDataSource properties

[Daniel John Debrunner <dj...@apache.org>]

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.

Dan.

Re: ConnectionPoolDataSource properties

[Kristian Waagan <Kr...@Sun.COM>]

Daniel John Debrunner wrote:
> Kristian Waagan wrote:
>> Hello,
>>
>>  From looking at the client driver, I get the impression the following 
>> expectation is valid:
>>
>> // Initial data source creation and configuration
>> ...
>> // Get physical connection
>> PooledConnection pc = cpDs.getPooledConnection();
>> // Get logical connection
>> Connection con = pc.getConnection();
>> ...
>> // Reconfigure data source
>> ...
>> // Get a new *logical* connection
>> con = pc.getConnection();
>> // The new logical connection has the changes made to the data source.
>>
>> I thought you had to get a new pooled connection for the changes to 
>> take effect.
>> Does anyone know?
> 
> I would expect the PooledConnection to retain its previous settings.

Thanks for your opinion Dan. I do expect the same.

> 
> 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
	- login timeout
	- retrieveMessageText

There might be others as well, as the reference to the data source (a 
public instance variable) is updated and information can be fetched from 
it anywhere the reference is available.

The reason why this is causing some trouble for me now, is that some 
required reset actions seem to be dependent on "recomputeFromDataSource" 
be true, but at the same time this condition breaks the current 
statement caching implementation.
The most puzzling one is the re-prepare of all open statements. If 
anyone knows if this was introduced for a specific reason, I would 
appreciate any information about it.

Given the circumstances, I don't feel comfortable starting to change too 
much of the existing code in the client driver. Instead, I'll try to add 
my own methods, either calling existing methods or copying existing code 
and change it as required. I, or anyone else for that matter, can fix 
this after the branch has been cut.
I know this approach has drawbacks, but breaking existing code to 
implement a probably not so heavily used feature is worse.

Please share your opinions if you disagree.


-- 
Kristian


> 
> Good catch!
> Dan.

Re: ConnectionPoolDataSource properties

[Daniel John Debrunner <dj...@apache.org>]

Kristian Waagan wrote:
> Hello,
> 
>  From looking at the client driver, I get the impression the following 
> expectation is valid:
> 
> // Initial data source creation and configuration
> ...
> // Get physical connection
> PooledConnection pc = cpDs.getPooledConnection();
> // Get logical connection
> Connection con = pc.getConnection();
> ...
> // Reconfigure data source
> ...
> // Get a new *logical* connection
> con = pc.getConnection();
> // The new logical connection has the changes made to the data source.
> 
> I thought you had to get a new pooled connection for the changes to take 
> effect.
> Does anyone know?

I would expect the PooledConnection to retain its previous settings.

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.

Good catch!
Dan.