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

Reply via email to