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 > > 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]
