commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matt Sicker <>
Subject Re: [DBCP] DelegatingConnection, hashCode(), and equals()
Date Thu, 07 Jun 2018 16:18:57 GMT
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 <> 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.
> Thoughts?
> Gary

Matt Sicker <>

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message