Thanks for your feedback Mark. Looking deeper into DBCP for a cleaner solution, it seems we are missing support for preparing callable statements in org.apache.commons.dbcp2.cpdsadapter.ConnectionImpl and org.apache.commons.dbcp2.cpdsadapter.PooledConnectionImpl. I see APIs implemented for prepareStatement(*) but not prepareCall(*). That's a big hole for our server. I'll look into filling it now...
Gary On Thu, Jun 7, 2018 at 1:09 PM, Mark Thomas <ma...@apache.org> wrote: > On 07/06/18 17:18, Matt Sicker wrote: > > This sounds like an honest bug that should be fixed, backwards > > compatibility be damned. I don't see how the old behavior is useful for > > anything other than connection starvation or some other strange behavior. > > I have completely the opposite view. > > There is nothing in the DBCP API that suggests that a Connection object > provided by the pool will ever be seen by the client again. > > The implementation below sounds like deliberate misuse of the pool. > Clients are not meant to retain references to objects that have been > returned to the pool. To do so is nearly always the cause of all sorts > of problems. I would be very strongly against any change that encouraged > that sort of misuse. > > What is the actual use case here? What is the purpose of retaining this > Map? Maybe we can come up with a better solution and/or an API change > that enables the requirement to be met without having to retain > references to connections after they have been returned to the pool. > > Mark > > > > > > On 7 June 2018 at 10:44, Gary Gregory <garydgreg...@gmail.com> wrote: > > > >> Hi All: > >> > >> I just ran into a case where different instances of subclasses > >> of DelegatingConnection like PoolGuardConnectionWrapper and > ConnectionImpl > >> are used as keys in a Map (Map<java.sql.Connection, Foo>) > >> > >> The problem is that when you borrow a Connection out of a pool, you get > a > >> new PoolGuardConnectionWrapper, so that the Map in the eventual call > site > >> grows and grows because the intention is that the Map key should be the > >> same when you borrow the same underlying Connection later. > >> > >> If DelegatingConnection implemented hashCode() and equals() to account > for > >> some or all of its instance variables, then one could use > >> DelegatingConnection instances as keys in a Map with the behavior I > expect, > >> YMMV. > >> > >> The issue is that implementing hashCode() and equals() where we did not > >> before could have unexpected side-effects for existing applications. > >> > >> Thoughts? > >> > >> Gary > >> > > > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > >
