If you're not concerned about these other errors, then Poolman (if you can still find it) might be a good fit. If I remember correctly, you could specify a SQL statement for it to execute ("select 1 from dual") before allocating a connection from the pool. If it got a SQLException, it would establish a new connection and return that.
--Kevin -----Original Message----- From: Rick Reumann [mailto:[EMAIL PROTECTED]] Sent: Tuesday, August 27, 2002 10:59 AM To: Struts Users Mailing List Subject: Re[2]: [OT] conn pooling - what next? On Tuesday, August 27, 2002, 10:49:45 AM, Kevin wrote: KAS> If the DBA is manually killing off your connections, then the KAS> pool needs to be paranoid about checking to see if the connection KAS> is available before each operation. So this adds overhead to KAS> using the pool. Is there a pool that does this checking? I might to suffer the overhead vs having the problems we have when our DBA messes around and kills stuff. KAS> In addition, consider this code: KAS> Connection cn = pool.allocate(); KAS> Statement stmt = cn.createStatement("some sql here"); KAS> ResultSet rs = stmt.execute(); KAS> Given the above, the pool could check the state of the connection KAS> before it returns from allocate(), but the other exception KAS> handling would be up to you. I'm not really concerned with the problem of there being an error for the short time after the connections are killed and someone just got a connection and is about to use it. The problem is that a new connection is not able to be gotten at all after they are killed. Thanks for any more help or advice. -- Rick mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>