Re: [DBCP] DelegatingConnection, hashCode(), and equals()
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.
On 7 June 2018 at 10:44, Gary Gregory <garydgregory@xxxxxxxxx> 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,
> The issue is that implementing hashCode() and equals() where we did not
> before could have unexpected side-effects for existing applications.
Matt Sicker <boards@xxxxxxxxx>