db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kristian Waagan <Kristian.Waa...@Sun.COM>
Subject Re: ConnectionPoolDataSource properties
Date Thu, 28 Feb 2008 18:45:32 GMT
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.


Mime
View raw message