commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Phil Steitz" <phil.ste...@gmail.com>
Subject Re: [DBCP] Release 1.3 soon?
Date Fri, 20 Jul 2007 06:19:38 GMT
On 7/19/07, Dain Sundstrom <dain@iq80.com> 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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message