On 7/19/07, Dain Sundstrom <[EMAIL PROTECTED]> wrote:
Are there any DBCP-1.3 release plans? Based on the JIRAs I think we are close to being ready to release. Are there any items that are planned but don't have JIRAs?
There are two things that I would like to at least talk about that relate to various JIRAs and comments on the list: 1) Intended current and future contract of close() on a connection pool, in particular the contract of BasicDataSource.close. The javadoc says "Close and release all connections that are currently stored in the connection pool associated with our data source." Some users interpret this - incorrectly - to mean that close will close *active* as well as idle connections. Even when AbandonedConfig is used (in which case the pool holds references to connections that have been checked out), close only closes idle connections (since the "pool" is really and idle object pool). So the answer to the question in, e.g. DBCP-221, is "sorry, no way to do that." Javadoc should be improved in any case. 2) Immutable-once-initialized status of BasicDataSource. I am inclined to close DBCP-221 as WONTFIX, but in this case we should rip out the remnants of what must have seemed like a good idea at the time to support "restart". This is sort of related to 1), because if we are going to attempt to allow BasicDataSource to be mutable once it has been initialized, I don't see any way to do that consistently without closing or appropriately modifying connections that have been checked out. Since we don't do that now, we can't really support this. My vote would be to keep BasicDataSource "immutable-once-initialized".
Here are some open JIRAs I think we can close: Fixed: DBCP-194 BasicDataSource.setLogWriter should not do createDataSource DBCP-102 setReadOnly & setAutoCommit called too many times DBCP-97 setAutoCommit(true) when returning connection to the pool DBCP-212 PoolingDataSource closes physical connections
+1 and thanks for verifying 97.
Invalid: DBCP-209 Is DataSource.getConnection(user, pass) working the way it is suppose to? User should be using either SharedPoolDataSource or the PerUserPoolDataSource. DBCP-53 commons dbcp does not supports Firebird DB Torque bug or misconfiguration by user.
+1
Won't fix DBCP-115 allow to set >= 6 parameters to do non-global SSL Request for mysql specific feature DBCP-152 add a socketFactory attribute to BasicDataSource (to allow SSL "thread"-safe) Request for mysql specific feature
+1 I would love to have a fix for DBCP-44; but that could wait on pool 1.4 if necessary (and Ipersonally see no way to fix it just within dbcp. It would be great if I was wrong on that). We should also address DBCP-4 (by using jdk logging, since we have bumped to 1.4 level). I think it would be good to start adding some simple instrumentation in 1.3 that we could add to in subsequent releases. Having things like physical connection opens / closes, pool high water marks, waits, etc., loggable would make debuggng and performance tuning much easier. I will finish reviewing recent patches tomorrow and come up with a straw man release plan this weekend if no one beats me to it. Thanks for all of your help on this, Dain. Phil --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
