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: [email protected] For additional commands, e-mail: [email protected]
