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
