On 22/11/2009, Phil Steitz <phil.ste...@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-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
