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 ConnectionPoolDataSource properties
Date Thu, 28 Feb 2008 16:36:22 GMT

 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 
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?


Here's a comment from am.Statement:
// If a dataSource is passed into resetClientConnection(), then we will 
// properties on the dataSource may have changed, and we will need to go 
// the open-statement list on the connection and do a full reset on all 
// 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.

View raw message