commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sebb <seb...@gmail.com>
Subject Re: [dbcp] 1.3 release problems
Date Sun, 22 Nov 2009 19:57:56 GMT
On 22/11/2009, Phil Steitz <phil.steitz@gmail.com> wrote:
> I am running into some problems preparing for dbcp-1.3.  I would
>  appreciate comments / patches on any of the issues below.
>
>  1. Findbugs is showing some real (inconsistent synch) and not so
>  real (e.g. serialization issues on classes that IMO should not be
>  serializable, but we can't fix until 2.0).  The full report is here:
>  http://commons.apache.org/dbcp/findbugs.html
>  I would appreciate suggestions/patches/commits for what to fix and how.

org.apache.commons.dbcp.AbandonedTrace$AbandonedObjectException.format
- not a problem, as the code is synch. on format, just disable the report

org.apache.commons.dbcp.PoolableConnectionFactory._connFactory,_pool,_validationQuery
=> just make these volatile.

org.apache.commons.dbcp.PoolingConnection.createKey(String, byte)
might ignore java.lang.Exception (lines218, 229, 240 and 251)
No idea

PoolingConnection$PStmtKey.PoolingConnection$PStmtKey._resultSetType
could be null and is guaranteed to be dereferenced in
org.apache.commons.dbcp.PoolingConnection.makeObject(Object)
This looks like a bug; just check for null in the second condition?

Class org.apache.commons.dbcp.cpdsadapter.DriverAdapterCPDS defines
non-transient non-serializable instance field logWriter
Just make the logWriter transient.

_pool synch: add synch or make volatile.
<aside>
Seems to me a lot of these synch. problems would be avoided if the
variables did not have set() methods - why are there set() methods for
fields that are provided in the constructors? What is the use case for
this?
</aside>

It would be helpful to know which classes are intended to be
thread-safe, as it's not clear whether the potential synch. problems
are likely to occur in normal usage or not.

For example the class SharedPoolDataSource: the field "pool" is
sometimes synch., and sometimes not, but the fields maxActive,
maxWait, maxIdle are not synch. at all.

The use of synchronization seems rather haphazard to me.

>  2. We can't compile commons-pool-1.3.jar against JDK 1.6 (JDBC 4)
>  and expect it to work for JDK 1.4/1.5 (JDBC 3) clients (at least not
>  as the code stands today).  So we need to create two jar artifacts.

How difficult would it be to support both in the same jar?

>   The question is which one gets the 1.3 name, what is the other
>  named and how do we package the distros?
>
>  3. I assume it is OK at this point to drop the nojdbc3 Ant target
>  and compiler flags for JDBC 2.
>
>  TIA
>
>  Phil
>
>  ---------------------------------------------------------------------
>  To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>  For additional commands, e-mail: dev-help@commons.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message