commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "pd (JIRA)" <j...@apache.org>
Subject [jira] Created: (DBCP-265) Connection close handling DatabaseMetaData exceed max open cursor oracle
Date Tue, 08 Apr 2008 08:21:24 GMT
Connection close handling DatabaseMetaData exceed max open cursor oracle
------------------------------------------------------------------------

                 Key: DBCP-265
                 URL: https://issues.apache.org/jira/browse/DBCP-265
             Project: Commons Dbcp
          Issue Type: Bug
    Affects Versions: 1.2.2, 1.2.1
         Environment: Windows/Unix, Oracle 10gR2, JDK 1.4, Oracle JDBC Driver 10.2.0.1. 
            Reporter: pd


Hello,

i was suprised by following behavior:
/**
* Here all is OK, the finally block closes the connection and implicit the statement and the
resultset. If called repeatedly, only one cursor is used.
* @throws SQLException
*/
public void test2() throws SQLException{
Connection con = null;
try{
con = dataSource.getConnection();
Statement statement = con.createStatement();
ResultSet resultSet = statement.executeQuery("select * from MyTable");
if(resultSet.next())
resultSet.getString(1);
}finally {
if (con != null) {
con.close();
}
}
}


But doing this repeatedly
/**
* Danger: exceeds max open cursors if called repeatedly.
* @throws SQLException
*/
public void test1() throws SQLException{
Connection con = null;
try{
con = dataSource.getConnection();
DatabaseMetaData metaData = con.getMetaData();
ResultSet schemas = metaData.getSchemas();
}finally {
if (con != null) {
con.close();
}
}
}
exceeds max open cursors on the database.

DataSource created with following block:
		dataSource = new BasicDataSource();
		dataSource.setDriverClassName("oracle.jdbc.OracleDriver");
		dataSource.setUsername("myuser");
		dataSource.setPassword("mypasswd");
		dataSource.setUrl("jdbc:oracle:thin:@192.168.0.1:1521:mydb");


Of course, explicit closing the 'schemas' ResultSet in the second case solves the problem.

I am not certainly sure my expected behavior is conform to the jdbc spec. But without using
the BasicDatasource this problem doesnt occure.

I inspected the code and saw, that org.apache.commons.dbcp.BasicDataSource (or more specific,
DelegatingConnection) doesnt track Connections and ResultSets created from DatabaseMetadata-Object.Only
created Statements form DelegatingConnection are tracked. And in PoolableConnectionFactory.passivateObject()
only these statements are closed and warnings are cleared on the underlying connection.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message