commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Phil Steitz <>
Subject Re: [POOL2][PROPOSAL] releasing commons-pool2-2.0-beta1
Date Thu, 05 May 2011 18:08:25 GMT
On 5/5/11 10:27 AM, Mark Thomas wrote:
> On 05/05/2011 18:21, Phil Steitz wrote:
>> On 5/5/11 9:42 AM, Mark Thomas wrote:
>>> On 05/05/2011 17:33, Phil Steitz wrote:
>>>> On 5/5/11 9:20 AM, Gary Gregory wrote:
>>>>> I would like to propose an aggressive release schedule:
>>>>> - Push 2.0 out as a generified version of 1.5 ASAP and add/remove/fiddle
>>>>> nothing else. "Just give me the generics P L E A S E!" :) Change deprecated
>>>>> documentation from "Will be removed in 2.0" to "Will be removed in 3.0".
>>>> Why such a rush to just get generics?  Honestly, this makes no sense
>>>> to me.  If you really want a type-safe pool, it is easy enough to
>>>> wrap the methods that borrow and return objects.  If we make this
>>>> decision, we are effectively deciding that the current pool API is
>>>> going to be *the* API for several years to come.  We may also be
>>>> painting ourselves into a performance corner supporting all of the
>>>> features in the current API.  We won't know that until we really get
>>>> the DBCP integration and performance testing done.
>>> +1. The good news is that I now have some time to work on this.
>> Great!
>>> The first task will be updating dbcp/trunk to build against pool/trunk.
>> +1 - but lets try to minimize the changes for now to those necessary
>> to get the build to work (i.e., hold off on internally
>> "genericising" DBCP).  This will make it easier to port bug fixes.
> OK. I've already added the @Override markers but that shouldn't cause
> too much pain. I'll hold off the generics changes for now and focus on
> pool2 performance.
>>> I suspect we are going to need at least a snapshot build of pool/trunk
>>> to keep the Maven deps happy.
>> I wonder if it would be just as easy to just move to using Ant for
>> this phase of dbcp development and either build a pool jar or just
>> pull in the required pool sources?  I would personally be fine with
>> that approach.
> My own plan (which is working already) is have the Tomcat DBCP/jdbc-pool
> performance tests as one Eclipse project which in turn depends on an
> Eclipse project for dbcp2 which in turn depends on an Eclipse project
> for pool2. I don't actually care right now that both the Ant and Maven
> builds for DBCP are broken. Others (and the CI systems) might ;)
> One option (that might also work for Gary) is to start producing
> snapshot builds of pool2.
Re performance, don't forget to add something that skips the synch
in createDataSource - i.e., use a PoolingDataSource directly to
avoid the thread lineup on getConnection due to that internal synch.

> Mark
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message