commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Phil Steitz <>
Subject Re: [dbcp] Callable statement pooling (DBCP-204)
Date Sun, 01 Nov 2009 19:00:00 GMT
Phil Steitz wrote:
> Mark Thomas wrote:
>> 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.
> +1
>>> 3) Leave implementation as is but add a new KeyedObjectPool for
>>> callable statements
>> Strikes me as adding unnecessary complexity.
> +1
>>> 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.
> I agree with you.  I had never run into this and was frankly
> surprised when I realized that the current impl works this way.  I
> guess the documentation for maxOpenPreparedStatements is vague
> enough (no mention of SQLExceptions on pool exhaustion) that we
> could change the behavior now (in 1.3).
> I will create a patch using a LinkedHashMap for the cache and attach
> it to DBCP-204.

Crap.  Just realized that _pstmtPool is a &%^$# *protected* field in
PoolingConnection.  I am inclined to ignore this compat break.
Interested in what others think.

> Phil
>> Mark
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:
>> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message