commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Josh Wyatt <josh.wy...@hcssystems.com>
Subject Re: DBCP 1.2.2: configuring defaultReadOnly param
Date Tue, 03 Feb 2009 15:09:55 GMT
Phil Steitz wrote:
>> Is there any way for me to get this fix into my production 
>> environment?  I could not even find a way to download the 1.3 source 
>> tree.
> work to get out).   If you are OK building a fork from source you could 
> download the 1.2.2 source distribution 
> (http://commons.apache.org/downloads/download_dbcp.cgi) and replace 
> PerUserPoolDataSource#setupDefaults with the version of this method in 
> svn trunk.  The fix for DBCP-207 should be backward compatible,  so that 
> should work.  Alternatively, if you don't want to fork, you could 
> subclass PerUserPoolDataSource (and its factory), overriding the 
> setupDefaults method with the version in the current source.
> 
> Phil

Phil,

Thanks again for your input and direction.

I compared the 1.3 version against the 1.2.2 version of PerUserPoolDataSource.java, and backported
the relevant change to 1.2.2 for a local fork, with the following patch (also attached) against
the 1.2.2 source tree:

--- commons-dbcp-1.2.2-src/src/java/org/apache/commons/dbcp/datasources/PerUserPoolDataSource.java
     2007-03-25 17:51:25.000000000 -0400
+++ commons-dbcp-1.2.2b-src/src/java/org/apache/commons/dbcp/datasources/PerUserPoolDataSource.java
    2009-01-31 09:36:31.000000000 -0500
@@ -419,7 +419,9 @@
         if (defaultTransactionIsolation != UNKNOWN_TRANSACTIONISOLATION) {
             con.setTransactionIsolation(defaultTransactionIsolation);
         }
-        con.setReadOnly(defaultReadOnly);
+        if (con.isReadOnly() != defaultReadOnly) {
+           con.setReadOnly(defaultReadOnly);
+       }
     }
 
     /**


We were able to recompile the jar file and test.  Results are that PerUserPoolDataSource does
not issue 'SET TRANSACTION' statements under any of the following configuration cases:

1. defaultReadOnly true
2. defaultReadOnly false
3. defaultReadOnly not set.

This is sufficient for our purposes, but may not be for everybody.  As it stands, we are still
testing with our application, but it appears to be a good workaround for our particular situation.
 Feel free to consider rolling it into a possible 1.2.3 release or similar backport effort.

I have also updated DBCP-282 with this information.

Thanks again,
josh

Mime
View raw message