You're right, I did miss that.  

So, I guess it's safe to assume that dbcp does wouldn't help with this issue?  Or I 
guess the automatic clean up of idle connections might help in this case?  

Travis



---- Original Message ----
From: [EMAIL PROTECTED]
Sent: 2003-03-10
To: Jakarta Commons Users List <[EMAIL PROTECTED]>
Subject: RE: Re: DBCP and ORA-01000: Maximum open cursors exceeded

Travis,

you missed this:

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

in Craig's email....
--
dIon Gillard, Multitask Consulting
Blog:      http://www.freeroller.net/page/dion/Weblog
Work:      http://www.multitask.com.au


[EMAIL PROTECTED] wrote on 11/03/2003 05:27:36 PM:

> You're design pattern would make Oracle choke in no time.  And that is
> the design pattern that most people would take, the problem is that 
> oracle requires full closing of ResultSet and statements as well as 
> connections.  I believe it's even stated in docs that closing a 
> connection will close everything eventually, or closing a statement 
> will close the resultsets eventually.  not so with oracle. 
> 
> Travis
> 
> ---- Original Message ----
> From: "Craig R. McClanahan" <[EMAIL PROTECTED]>
> Sent: 2003-03-10
> To: Jakarta Commons Users List <[EMAIL PROTECTED]>
> Subject: Re: DBCP and ORA-01000: Maximum open cursors exceeded
> 
> 
> 
> On Mon, 10 Mar 2003 [EMAIL PROTECTED] wrote:
> 
> > Date: Mon, 10 Mar 2003 21:11:18 -0700 (MST)
> > From: [EMAIL PROTECTED]
> > Reply-To: Jakarta Commons Users List <[EMAIL PROTECTED]>
> > To: [EMAIL PROTECTED]
> > 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: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to