Phil Steitz wrote: > 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.
OK, I am now feeling stupid. GKOP already has LRU-cache like behavior. (See clearOldest test in allocate()). Given compat issues, I am inclined to move forward with 0). Phil > > 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]
