You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@commons.apache.org by "pd (JIRA)" <ji...@apache.org> on 2008/04/08 10:21:24 UTC
[jira] Created: (DBCP-265) Connection close handling
DatabaseMetaData exceed max open cursor oracle
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.
[jira] Updated: (DBCP-265) Connection close handling
DatabaseMetaData exceed max open cursor oracle
Posted by "Henri Yandell (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DBCP-265?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Henri Yandell updated DBCP-265:
-------------------------------
Fix Version/s: 1.3
Sounds like we need a DelegatingMetaData.
> 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.1, 1.2.2
> Environment: Windows/Unix, Oracle 10gR2, JDK 1.4, Oracle JDBC Driver 10.2.0.1.
> Reporter: pd
> Fix For: 1.3
>
>
> 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.
[jira] Resolved: (DBCP-265) Connection close handling
DatabaseMetaData exceed max open cursor oracle
Posted by "Mark Thomas (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DBCP-265?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Mark Thomas resolved DBCP-265.
------------------------------
Resolution: Fixed
This has been fixed in svn and will be included in 1.3 onwards
> 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.1, 1.2.2
> Environment: Windows/Unix, Oracle 10gR2, JDK 1.4, Oracle JDBC Driver 10.2.0.1.
> Reporter: pd
> Fix For: 1.3
>
>
> 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.
[jira] Closed: (DBCP-265) Connection close handling
DatabaseMetaData exceed max open cursor oracle
Posted by "Phil Steitz (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DBCP-265?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Phil Steitz closed DBCP-265.
----------------------------
> 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.1, 1.2.2
> Environment: Windows/Unix, Oracle 10gR2, JDK 1.4, Oracle JDBC Driver 10.2.0.1.
> Reporter: pd
> Fix For: 1.3
>
>
> 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.