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. Phil > > Mark > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
