Mailing-List: contact dev-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Commons Developers List" <dev@commons.apache.org>
Received-SPF: neutral (athena.apache.org: local policy)
Message-ID: <4AEDB35B.6000207@apache.org>
Date: Sun, 01 Nov 2009 08:12:11 -0800
From: Mark Thomas <markt@apache.org>
User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812)
MIME-Version: 1.0
To: Commons Developers List <dev@commons.apache.org>
Subject: Re: [dbcp] Callable statement pooling (DBCP-204)
References: <4AEC659D.6040907@gmail.com>
In-Reply-To: <4AEC659D.6040907@gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Phil Steitz wrote:
> I agree that DBCP should support callable statement pooling and the
> patch attached to DBCP-204 is a reasonable way to do it.  What I am
> concerned about is that adding callable statements to the prepared
> statement pool with the current implementation may break some
> applications by causing them to go beyond MaxPreparedStatements.
> Unfortunately, the current behavior is to throw SQLException on
> prepareStatement when this happens.  I see four options.
> 
> 0) Damn the torpedoes - apply patch as is
Agree - too risky.

> 1) Change the prepared statement pool to behave as an LRU cache
This is looks like the best way to go to me,

> 2) Stick with KeyedObjectPool implementation, but create and do not
> pool new statements when the pool is exhausted
I can think of scenarios where this could negate the benefit of the pooling in
the first place. 1) seems the better choice.

> 3) Leave implementation as is but add a new KeyedObjectPool for
> callable statements
Strikes me as adding unnecessary complexity.

> I think 1) is the best option, but it is a significant change in
> behavior, so should probably wait until 2.0
I can see where you are coming from but how many folks would actually complain
that a SQLException wasn't thrown if their code opened too many statements? If
we can see any scenarios where this would cause problems, then lets wait for
2.0. If we can't (and I can't right now), I'd vote for 1.3.

Mark


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