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.
