commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Michael Holly" <>
Subject Broken Pipe error in DBCP when DB has been restarted.
Date Tue, 06 May 2003 17:07:31 GMT

I am running Tomcat 4.1.18, Oracle 8.1.7 using the thin driver, and Commons

My problem mainly stems from the fact that my company has a policy to reboot
the database server every night. I know, I know, Oracle on Sun should run

Anyway, I can't get around the policy. Perhaps someone here can help me get
around it.

Since the DB gets restarted, the connections that the pool has open become
invalid. My application gets a SQLException: IoException: Broken Pipe error
when ever I try access the JSP page in the morning. It is configured with
two connections and the page will error out twice before finally rendering.

I'm in the process of adding a validation query to my pool, but I am not
sure that this will help. See link for details

I'm not real happy about this validation query because it is just more
network traffic. I'm interseted in the 3rd option described in the snippet
below.  Can anyone point me how to configure my pool like this?



> Weblogic's JDBC pool has two options:
> 1. Validate on checkout
> 2. Validation on return
> You can select any or none of the options.  If you don't select any and
> the pooled connections go bad, then you'll get bad connections when
> checking out. I personally like validating the connection on checkout,
> although your code is then tied to a pool that does this.
> -Dave

Right, and DBCP does those two options, plus a third: validation while
idle, the periodically walks through the connections sitting idle in the
pool and evicts the ones that go bad.

Personally, I use the third option almost exclusively, attempting to
strike some balance between the validation overhead and the time it will
take the app to recover (i.e., purge the bad connections and establish new

It's really the same problem with or without pooling, sometimes your
connection will go bad.  Validation or failure detection can't prevent
this problem, it can only try to minimize it.  (For example, assume you've
got this magical "detect a dropped connection and quietly substitute a
valid one, at any point in the client code" facility.  It's still possible
for a connection to be dropped in the midst of a client transaction, and
there may be little the connection wrapper can do to make that problem
quietly go away.  Record and replay the executed statements?  How do you
know whether the exception-throwing statement made it to the database or


View raw message