Re: [DBCP] DelegatingConnection, hashCode(), and equals()
Thanks for your feedback Mark.
Looking deeper into DBCP for a cleaner solution, it seems we are missing
support for preparing callable statements
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...
On Thu, Jun 7, 2018 at 1:09 PM, Mark Thomas <markt@xxxxxxxxxx> 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.
> > 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
> >> 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
> >> new PoolGuardConnectionWrapper, so that the Map in the eventual call
> >> 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
> >> some or all of its instance variables, then one could use
> >> DelegatingConnection instances as keys in a Map with the behavior I
> >> 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-unsubscribe@xxxxxxxxxxxxxxxxxx
> For additional commands, e-mail: dev-help@xxxxxxxxxxxxxxxxxx