commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ben Walding <default0...@walding.com>
Subject Re: DBCP and ORA-01000: Maximum open cursors exceeded
Date Tue, 11 Mar 2003 07:48:03 GMT
One thing that I find makes my life a lot easier when dealing with JDBC 
is to use the attached JDBCUtility

JDBCUtility.close(rs);
JDBCUtility.close(stmt);
JDBCUtility.close(pstmt);
JDBCUtility.close(conn);

It checks to see if the reference is null, and if not, tries to close it.
It also catches any exceptions thrown during closing - which 99.999% of 
people don't care about anyway.

I find that as it is simpler to do, there is a greater chance of me 
actually doing it...



  DataSource ds = ...; // Acquire a reference to your connection pool
  Connection conn = null;
  Statement stmt = null;
  ResultSet rs = null;
  try {
    conn = ds.getConnection();
    ... use "conn" to do some database access stuff ...
    ... passing the "conn" instance to any subordinate methods ...
    ... that need access to this connection ...
  } catch (SQLException e) {
    ... deal with database errors ...
  } finally {
    JDBCUtility.close(rs);
    JDBCUtility.close(stmt);
    JDBCUtility.close(conn);
  }


>
>  
>
>>My personal opinion is that it is not the responsibility of a connection
>>pool to make up for application developer screw-ups.  App developers can
>>make nearly all of this kind of problem go away if they would follow a
>>very simple design pattern:
>>
>>  DataSource ds = ...; // Acquire a reference to your connection pool
>>  Connection conn = null;
>>  Statement stmt = null;
>>  ResultSet rs = null;
>>  try {
>>    conn = ds.getConnection();
>>    ... use "conn" to do some database access stuff ...
>>    ... passing the "conn" instance to any subordinate methods ...
>>    ... that need access to this connection ...
>>  } catch (SQLException e) {
>>    ... deal with database errors ...
>>  } finally {
>>    if (conn != null) {
>>      try {
>>        conn.close(); // Return connection to the pool
>>      } catch (SQLException e) {
>>        ... report a really bad problem ...
>>      }
>>  }
>>
>>You can extend this to cleaning up open Statement and/or ResultSet 
>>    
>>
>objects
>  
>
>>in the "finally" block as well.  Related to DBCP in particular, I would
>>never personally use the "abandoned connection" feature -- if it makes a
>>difference for your app, that means you are leaking connections 
>>    
>>
>someplace,
>  
>
>>and the right answer is to fix the underlying problem.  The above design
>>pattern does that.
>>
>>Craig McClanahan
>>
>>    
>>
>>>Travis Reeder
>>>Space Program
>>>http://www.spaceprogram.com
>>>
>>>---------------------------------------------------------------------
>>>To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
>>>For additional commands, e-mail: commons-user-help@jakarta.apache.org
>>>
>>>
>>>      
>>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
>>For additional commands, e-mail: commons-user-help@jakarta.apache.org
>>
>>
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
>>For additional commands, e-mail: commons-user-help@jakarta.apache.org
>>
>>    
>>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: commons-user-help@jakarta.apache.org
>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: commons-user-help@jakarta.apache.org
>
>
>  
>


Mime
  • Unnamed multipart/mixed (inline, None, 0 bytes)
View raw message