Re: [DBCP] DelegatingConnection, hashCode(), and equals()
After fixing prepared statements in the cpdsadapter package, I found a
cleaner solution that delegates all prepared and callable statement pooling
to DBCP's cpdsadapter.
Thank you for the feedback.
I think I am ready to create an RC for DBCP 2.4.0.
On Thu, Jun 7, 2018 at 5:01 PM Gary Gregory <garydgregory@xxxxxxxxx> wrote:
> 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...
> 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
>> 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 a
>> >> 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