Return-Path: <craigmcc@apache.org>
Mailing-List: contact commons-user-help@jakarta.apache.org; run by ezmlm
Delivered-To: mailing list commons-user@jakarta.apache.org
Received: (qmail 49154 invoked from network); 11 Mar 2003 06:08:16 -0000
Received: from icarus.apache.org (208.185.179.13)
  by daedalus.apache.org with SMTP; 11 Mar 2003 06:08:16 -0000
Received: (qmail 93183 invoked by uid 1059); 11 Mar 2003 06:08:14 -0000
Received: from localhost (sendmail-bs@127.0.0.1)
  by localhost with SMTP; 11 Mar 2003 06:08:14 -0000
Date: Mon, 10 Mar 2003 22:08:14 -0800 (PST)
From: "Craig R. McClanahan" <craigmcc@apache.org>
To: Jakarta Commons Users List <commons-user@jakarta.apache.org>
Subject: Re: DBCP and ORA-01000: Maximum open cursors exceeded
In-Reply-To: <7127716.1047355878984.JavaMail.SYSTEM@bodisafa>
Message-ID: <20030310220037.Y51755@icarus.apache.org>
References: <7127716.1047355878984.JavaMail.SYSTEM@bodisafa>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Spam-Rating: localhost 1.6.2 0/1000/N
X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N



On Mon, 10 Mar 2003 travis@spaceprogram.com wrote:

> Date: Mon, 10 Mar 2003 21:11:18 -0700 (MST)
> From: travis@spaceprogram.com
> Reply-To: Jakarta Commons Users List <commons-user@jakarta.apache.org>
> To: commons-user@jakarta.apache.org
> Subject: DBCP and ORA-01000: Maximum open cursors exceeded
>
> Does DBCP handle this issue at all?
>
> I realize it's probably some missed statements being closed or something
> in the application or something, but this is such common problem (just
> search google for it to see), that I wonder if DBCP makes an effort to
> help this, like clean things up automatically or anything.
>

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
>
>