[
https://issues.apache.org/jira/browse/DBCP-293?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eugene Krylov resolved DBCP-293.
--------------------------------
Resolution: Fixed
Fix Version/s: 1.3
This appears to be working in the latest trunk version. Sorry about any
inconvenience.
> Closed statement exception using Oracle 11g and JDK Jrockit 1.6
> ---------------------------------------------------------------
>
> Key: DBCP-293
> URL: https://issues.apache.org/jira/browse/DBCP-293
> Project: Commons Dbcp
> Issue Type: Bug
> Affects Versions: 1.2.1
> Environment: dbcp 1.2.1
> Oracle 11g,
> oracle driver from weblogic 10.3 distribution
> server/ext/jdbc/oracle/11g/ojdbc6.jar,
> $ java -version
> java version "1.6.0_05"
> Java(TM) SE Runtime Environment (build 1.6.0_05-b13)
> BEA JRockit(R) (build R27.6.0-50_o-100423-1.6.0_05-20080626-2104-linux-ia32,
> compiled mode)
> Reporter: Eugene Krylov
> Fix For: 1.3
>
>
> After upgrade to latest version of weblogic which now includes jdk 1.6 I am
> running into an exception where statements appear to be closed but still
> reside in the statement cache. It appears related to transaction rollback and
> closing of connection for which statement was originally prepared. Exception
> stack is as follows:
> java.sql.SQLException: Closed Statement
> at
> oracle.jdbc.driver.SQLStateMapping.newSQLException(SQLStateMapping.java:70)
> at
> oracle.jdbc.driver.DatabaseError.newSQLException(DatabaseError.java:112)
> at
> oracle.jdbc.driver.DatabaseError.throwSqlException(DatabaseError.java:173)
> at
> oracle.jdbc.driver.DatabaseError.throwSqlException(DatabaseError.java:229)
> at
> oracle.jdbc.driver.DatabaseError.throwSqlException(DatabaseError.java:403)
> at
> oracle.jdbc.driver.OracleClosedStatement.setQueryTimeout(OracleClosedStatement.java:2438)
> at
> oracle.jdbc.driver.OracleStatementWrapper.setQueryTimeout(OracleStatementWrapper.java:250)
> at
> org.apache.commons.dbcp.DelegatingStatement.setQueryTimeout(DelegatingStatement.java:246)
> at
> org.apache.commons.dbcp.DelegatingStatement.setQueryTimeout(DelegatingStatement.java:246)
> at
> com.healthedge.j2ee.DBConnectionImpl.prepareStatement(DBConnectionImpl.java:208)
> Jocl file looks like this:
> <?xml version="1.0"?>
> <object class="org.apache.commons.dbcp.PoolableConnectionFactory"
> xmlns="http://apache.org/xml/xmlns/jakarta/commons/jocl";>
>
> <!--
> The first argument to PoolableConnectionFactory is a ConnectionFactory.
> We'll use a DriverManagerConnectionFactory, passing in the appropriate
> connect string for the underlying driver.
> -->
> <object class="org.apache.commons.dbcp.DriverManagerConnectionFactory">
> <string value="jdbc:oracle:thin:@localhost:1521:orcl"/>
> <string value="schema"/>
> <string value="password"/>
> </object>
>
> <!--
> The next argument is the pool to use. We'll use a StackObjectPool,
> although any implementation of ObjectPool should suffice.
>
> Since we are running on single connection from the client anyway,
> there is not a need to tune this to perfection.
> -->
> <object class="org.apache.commons.pool.impl.StackObjectPool"/>
>
> <!--
> The next argument is the KeyedObjectPoolFactory to use to create pools
> for storing PreparedStatements. This functionality is optional, it can
> be disabled by using the line below.
> <object class="org.apache.commons.pool.KeyedObjectPoolFactory"
> null="true"/>
> -->
> <object class="org.apache.commons.pool.impl.GenericKeyedObjectPoolFactory">
> <object class="org.apache.commons.pool.KeyedPoolableObjectFactory"
> null="true"/>
>
> <int value="20"/>
> <byte value="2"/>
> <long value="2000"/>
> <int value="200"/>
> <int value="300"/>
> </object>
> <!--
> The next argument is the query to use to validate that a Connection is
> still up and running. It should return at least one row.
> This functionality is optional. We'll just set it to null.
> <string null="true"/>
> -->
> <string value="select 1 from age_range"/>
> <boolean value="false"/> <!-- The default "read only" value for
> Connections. -->
> <boolean value="false"/> <!-- The default "auto commit" value for
> Connections. -->
>
> </object>
> Disabling statement cache eliminates the exception.
> This is my first time reporting an issue in this forum, so if I filed it in a
> wrong place please let me know. I searched bugs, but have not found anything
> that would be similar to this.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
