Mailing-List: contact user-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Jakarta Commons Users List" <user@commons.apache.org>
Received-SPF: pass (athena.apache.org: domain of phil.steitz@gmail.com
 designates 64.233.182.187 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=beta;
        h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=OlKqPdpq+4lOJDqIAjtp6ZakA/tx5AwosYQGp5I4h9by7BRxZi+3Z6foo3oNYW2uBqPn6krA3Eqd67KIVWFDAeq8vCqH7BGB6bOBx59bWoKQWqvrW0gtYVwM8BPTphBV8RTaBeErusHOvoJN+Qzygr1Kw8nWhjSQZ3cN6VTPAR8=
Message-ID: <8a81b4af0709061313j21ccb12cg29d6117c1662ce41@mail.gmail.com>
Date: Thu, 6 Sep 2007 13:13:15 -0700
From: "Phil Steitz" <phil.steitz@gmail.com>
To: "Jakarta Commons Users List" <user@commons.apache.org>,
	stafford@marine.rutgers.edu
Subject: Re: DBCP - behavior of dbcp when db is restarted
In-Reply-To: <46DF0DC2.2000602@marine.rutgers.edu>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <46DF0DC2.2000602@marine.rutgers.edu>

On 9/5/07, Wm.A.Stafford <stafford@marine.rutgers.edu> wrote:
> We are using DBCP in a refactored web application that, in the past,
> used a locally written connection pool.  This original pool always
> checked a connection object to see if it was NULL before handing it
> out.  I was told that this was because the  DB was unstable at one point
> and the pool was handing out connections that were null after a db restart.
>
> I would like to know if this is an issue with DBCP.  I can't image that
> it would be, this seems like a common enough situation.  However, the
> higher ups are concerned that we have subtracted functionality by using
> DBCP.

DBCP can be configured to validate connections before lending them
them to clients. Its method of doing so is to execute a "validation
query" that must return at least one row to succeed.  There is
currently no built-in facility for testing for null or bad connections
other than this.  Assuming you are using BasicDataSource, the relevant
configuration parameters to ensure connections are tested before being
returned to clients are testOnBorrow and validationQuery (see
http://commons.apache.org/dbcp/configuration.html).  You can also
force connections to be tested when they are returned to the pool by
setting testOnReturn to true.

DBCP's abilities to handle network and database failure / recovery
scenarios are primitive - validation as above is pretty much all that
exists and validation queries can hang in the event of a network
failure (see http://issues.apache.org/jira/browse/DBCP-226).  Patches,
suggestions for improvement are welcome.

Phil

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@commons.apache.org
For additional commands, e-mail: user-help@commons.apache.org