You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Mark Thomas <ma...@apache.org> on 2011/03/22 18:46:41 UTC
[DBCP] The plan for v2
Don't let the title get your hopes up. I don't have one yet, at least
not a complete one.
One of the primary driver for pool2 was to make use of
java.util.concurrent for the pool implementation and significantly
improve DBCP performance on multi-core systems (re-using ideas where we
can from Tomcat's jdbc-pool). I'm at the point where I have some time to
work on this.
My very outline plan was as follows:
a) get DBCP working with pool2
b) run the jdbc-pool performance tests to see how much ground we need to
catch up
c) improve the pool2 implementation until we get somewhere close to
jdbc-pool
a) is non-trival and is really the focus of this e-mail.
Issue 1
=======
DBCP isn't going to be able to use pool2 without some major re-factoring.
My solution is:
- copy current dbcp trunk to a branch
- rename o.a.commons.dbcp to o.a.commons.dbcp2
- update dependencies from pool to pool2
- get it working
Issue 2
=======
DBCP also ships with the o.a.commons.jocl package.
There have been no jocl related questions on the users list since 2007.
To prevent clashes between dbcp1 and dbcp2 I propose to simply drop JOCL
support in dbcp2.
Issue 3
=======
Minimum Java version.
Supporting multiple JDBC API versions is a nuisance. I propose switching
to a jdbc-pool style proxy approach. I also propose a minimum Java
version of 5 to align with pool2.
Issue 4
=======
Will the new dbcp work with Servlet containers?
There were some concerns in this area with the pool2 re-factoring. This
needs to be tested but my turn out to be a non-issue.
I think these 4 issues need to be resolved before there is a pool2 or
dbcp2 release.
Assuming there are no objections, I plan to start committing along these
lines in the next couple of days.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [DBCP] The plan for v2
Posted by Phil Steitz <ph...@gmail.com>.
On 4/23/11 10:08 AM, Simone Tripodi wrote:
> Hi Phil,
> I deduce to overlook, for now, also methods marked as @deprecated,
> (typically the setFactory() methods), right?
> Thanks in advance!
> Simo
>
Fine by me.
Phil
> http://people.apache.org/~simonetripodi/
> http://www.99soft.org/
>
>
>
> On Sat, Apr 23, 2011 at 6:14 PM, Phil Steitz <ph...@gmail.com> wrote:
>> On 4/23/11 8:07 AM, Simone Tripodi wrote:
>>> GREAT, thanks Phil!!!
>>> I'm going to checkout the current trunk and updating pool code!!!
>>> Have a nice weekend!!!
>>> Simo
>> Great! Remember to update changes.xml in trunk with references to
>> issues as you bring things over. For now, let's just make the
>> generification changes (i.e., hold off on property name and
>> mutability changes). I will start working on dbcp, first attacking
>> the real issues against 1.x and then getting compilation against the
>> new pool to work in trunk.
>>
>> Phil
>>> http://people.apache.org/~simonetripodi/
>>> http://www.99soft.org/
>>>
>>>
>>>
>>> On Sat, Apr 23, 2011 at 5:04 PM, Phil Steitz <ph...@gmail.com> wrote:
>>>> On 3/22/11 11:20 AM, Mark Thomas wrote:
>>>>> On 22/03/2011 17:58, Gary Gregory wrote:
>>>>>> Hi Mark and all:
>>>>>>
>>>>>> It's good to hear someone is thinking about moving forward!
>>>>>>
>>>>>> pool2 trunk seems to me to be highly volatile based on having worked some in
>>>>>> pool2.
>>>>>>
>>>>>> I've read opinions here going back and forth as to how to solidify the API
>>>>>> or even go /back/ to the pool1 style before moving forward again.
>>>>>>
>>>>>> I think time would be better spent solidifying pool2. Time spent matching
>>>>>> dbcp2 to pool2 could be a waste because, to me, pool2 feels like a moving
>>>>>> target ATM.
>>>>> pool2 is a moving target because a lot of the re-factoring has been an
>>>>> academic exercise. Having a clear end user for this (Tomcat -> DBCP ->
>>>>> POOL) should provide the direction necessary to solidify pool2. I don't
>>>>> mind working with a moving target as long as it is moving towards a
>>>>> clear goal. That goal for me is:
>>>>> - Java 5 / generics
>>>>> - fixing inconsistencies / oddities
>>>>> - improved performance on DBCP in multi-core servers.
>>>>>
>>>>> It would certainly make starting dbcp2 a whole lot easier if most of the
>>>>> pool2 re-factoring had not taken place. I think we made a mistake in not
>>>>> pushing forward with DBCP and POOL in parallel. That said, I like a lot
>>>>> of the pool2 changes and don't want to throw them away.
>>>>>
>>>>> What do folks think to the following:
>>>>> - move pool trunk to a POOL_FUTURE branch
>>>>> - restore pool trunk to a copy of the POOL_1_X branch
>>>> Done.
>>>>
>>>> Phil
>>>>> - rename pool package to o.a.c.pool2
>>>>> (in reality this would probably be a merge from POOL_FUTURE)
>>>>> - rename dbcp packages to o.a.c.dbcp2
>>>>> - get pool2 and dbcp2 working together
>>>>> - get Tomcat trunk working with dbcp2
>>>>> - go through the POOL_FUTURE changes one at a time:
>>>>> - merging it into pool2 trunk
>>>>> - updating dbcp2 trunk if necessary
>>>>> - testing updated dbcp2 with Tomcat
>>>>> - if a POOL_FUTURE change breaks DBCP/Tomcat integration in a way that
>>>>> can't easily be fixed skip that change and leave it in POOL_FUTURE
>>>>>
>>>>> Mark
>>>>>
>>>>>> Min Java 5: +1!
>>>>>>
>>>>>> Gary
>>>>>>
>>>>>> On Tue, Mar 22, 2011 at 1:46 PM, Mark Thomas <ma...@apache.org> wrote:
>>>>>>
>>>>>>> Don't let the title get your hopes up. I don't have one yet, at least
>>>>>>> not a complete one.
>>>>>>> One of the primary driver for pool2 was to make use of
>>>>>>> java.util.concurrent for the pool implementation and significantly
>>>>>>> improve DBCP performance on multi-core systems (re-using ideas where we
>>>>>>> can from Tomcat's jdbc-pool). I'm at the point where I have some time to
>>>>>>> work on this.
>>>>>>>
>>>>>>> My very outline plan was as follows:
>>>>>>> a) get DBCP working with pool2
>>>>>>> b) run the jdbc-pool performance tests to see how much ground we need to
>>>>>>> catch up
>>>>>>> c) improve the pool2 implementation until we get somewhere close to
>>>>>>> jdbc-pool
>>>>>>>
>>>>>>> a) is non-trival and is really the focus of this e-mail.
>>>>>>>
>>>>>>> Issue 1
>>>>>>> =======
>>>>>>> DBCP isn't going to be able to use pool2 without some major re-factoring.
>>>>>>>
>>>>>>> My solution is:
>>>>>>> - copy current dbcp trunk to a branch
>>>>>>> - rename o.a.commons.dbcp to o.a.commons.dbcp2
>>>>>>> - update dependencies from pool to pool2
>>>>>>> - get it working
>>>>>>>
>>>>>>> Issue 2
>>>>>>> =======
>>>>>>> DBCP also ships with the o.a.commons.jocl package.
>>>>>>>
>>>>>>> There have been no jocl related questions on the users list since 2007.
>>>>>>> To prevent clashes between dbcp1 and dbcp2 I propose to simply drop JOCL
>>>>>>> support in dbcp2.
>>>>>>>
>>>>>>> Issue 3
>>>>>>> =======
>>>>>>> Minimum Java version.
>>>>>>>
>>>>>>> Supporting multiple JDBC API versions is a nuisance. I propose switching
>>>>>>> to a jdbc-pool style proxy approach. I also propose a minimum Java
>>>>>>> version of 5 to align with pool2.
>>>>>>>
>>>>>>> Issue 4
>>>>>>> =======
>>>>>>> Will the new dbcp work with Servlet containers?
>>>>>>>
>>>>>>> There were some concerns in this area with the pool2 re-factoring. This
>>>>>>> needs to be tested but my turn out to be a non-issue.
>>>>>>>
>>>>>>>
>>>>>>> I think these 4 issues need to be resolved before there is a pool2 or
>>>>>>> dbcp2 release.
>>>>>>>
>>>>>>>
>>>>>>> Assuming there are no objections, I plan to start committing along these
>>>>>>> lines in the next couple of days.
>>>>>>>
>>>>>>> Mark
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>>
>>>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>
>>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>
>>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [DBCP] The plan for v2
Posted by Simone Tripodi <si...@apache.org>.
Hi Phil,
I deduce to overlook, for now, also methods marked as @deprecated,
(typically the setFactory() methods), right?
Thanks in advance!
Simo
http://people.apache.org/~simonetripodi/
http://www.99soft.org/
On Sat, Apr 23, 2011 at 6:14 PM, Phil Steitz <ph...@gmail.com> wrote:
> On 4/23/11 8:07 AM, Simone Tripodi wrote:
>> GREAT, thanks Phil!!!
>> I'm going to checkout the current trunk and updating pool code!!!
>> Have a nice weekend!!!
>> Simo
>
> Great! Remember to update changes.xml in trunk with references to
> issues as you bring things over. For now, let's just make the
> generification changes (i.e., hold off on property name and
> mutability changes). I will start working on dbcp, first attacking
> the real issues against 1.x and then getting compilation against the
> new pool to work in trunk.
>
> Phil
>> http://people.apache.org/~simonetripodi/
>> http://www.99soft.org/
>>
>>
>>
>> On Sat, Apr 23, 2011 at 5:04 PM, Phil Steitz <ph...@gmail.com> wrote:
>>> On 3/22/11 11:20 AM, Mark Thomas wrote:
>>>> On 22/03/2011 17:58, Gary Gregory wrote:
>>>>> Hi Mark and all:
>>>>>
>>>>> It's good to hear someone is thinking about moving forward!
>>>>>
>>>>> pool2 trunk seems to me to be highly volatile based on having worked some in
>>>>> pool2.
>>>>>
>>>>> I've read opinions here going back and forth as to how to solidify the API
>>>>> or even go /back/ to the pool1 style before moving forward again.
>>>>>
>>>>> I think time would be better spent solidifying pool2. Time spent matching
>>>>> dbcp2 to pool2 could be a waste because, to me, pool2 feels like a moving
>>>>> target ATM.
>>>> pool2 is a moving target because a lot of the re-factoring has been an
>>>> academic exercise. Having a clear end user for this (Tomcat -> DBCP ->
>>>> POOL) should provide the direction necessary to solidify pool2. I don't
>>>> mind working with a moving target as long as it is moving towards a
>>>> clear goal. That goal for me is:
>>>> - Java 5 / generics
>>>> - fixing inconsistencies / oddities
>>>> - improved performance on DBCP in multi-core servers.
>>>>
>>>> It would certainly make starting dbcp2 a whole lot easier if most of the
>>>> pool2 re-factoring had not taken place. I think we made a mistake in not
>>>> pushing forward with DBCP and POOL in parallel. That said, I like a lot
>>>> of the pool2 changes and don't want to throw them away.
>>>>
>>>> What do folks think to the following:
>>>> - move pool trunk to a POOL_FUTURE branch
>>>> - restore pool trunk to a copy of the POOL_1_X branch
>>> Done.
>>>
>>> Phil
>>>> - rename pool package to o.a.c.pool2
>>>> (in reality this would probably be a merge from POOL_FUTURE)
>>>> - rename dbcp packages to o.a.c.dbcp2
>>>> - get pool2 and dbcp2 working together
>>>> - get Tomcat trunk working with dbcp2
>>>> - go through the POOL_FUTURE changes one at a time:
>>>> - merging it into pool2 trunk
>>>> - updating dbcp2 trunk if necessary
>>>> - testing updated dbcp2 with Tomcat
>>>> - if a POOL_FUTURE change breaks DBCP/Tomcat integration in a way that
>>>> can't easily be fixed skip that change and leave it in POOL_FUTURE
>>>>
>>>> Mark
>>>>
>>>>> Min Java 5: +1!
>>>>>
>>>>> Gary
>>>>>
>>>>> On Tue, Mar 22, 2011 at 1:46 PM, Mark Thomas <ma...@apache.org> wrote:
>>>>>
>>>>>> Don't let the title get your hopes up. I don't have one yet, at least
>>>>>> not a complete one.
>>>>>> One of the primary driver for pool2 was to make use of
>>>>>> java.util.concurrent for the pool implementation and significantly
>>>>>> improve DBCP performance on multi-core systems (re-using ideas where we
>>>>>> can from Tomcat's jdbc-pool). I'm at the point where I have some time to
>>>>>> work on this.
>>>>>>
>>>>>> My very outline plan was as follows:
>>>>>> a) get DBCP working with pool2
>>>>>> b) run the jdbc-pool performance tests to see how much ground we need to
>>>>>> catch up
>>>>>> c) improve the pool2 implementation until we get somewhere close to
>>>>>> jdbc-pool
>>>>>>
>>>>>> a) is non-trival and is really the focus of this e-mail.
>>>>>>
>>>>>> Issue 1
>>>>>> =======
>>>>>> DBCP isn't going to be able to use pool2 without some major re-factoring.
>>>>>>
>>>>>> My solution is:
>>>>>> - copy current dbcp trunk to a branch
>>>>>> - rename o.a.commons.dbcp to o.a.commons.dbcp2
>>>>>> - update dependencies from pool to pool2
>>>>>> - get it working
>>>>>>
>>>>>> Issue 2
>>>>>> =======
>>>>>> DBCP also ships with the o.a.commons.jocl package.
>>>>>>
>>>>>> There have been no jocl related questions on the users list since 2007.
>>>>>> To prevent clashes between dbcp1 and dbcp2 I propose to simply drop JOCL
>>>>>> support in dbcp2.
>>>>>>
>>>>>> Issue 3
>>>>>> =======
>>>>>> Minimum Java version.
>>>>>>
>>>>>> Supporting multiple JDBC API versions is a nuisance. I propose switching
>>>>>> to a jdbc-pool style proxy approach. I also propose a minimum Java
>>>>>> version of 5 to align with pool2.
>>>>>>
>>>>>> Issue 4
>>>>>> =======
>>>>>> Will the new dbcp work with Servlet containers?
>>>>>>
>>>>>> There were some concerns in this area with the pool2 re-factoring. This
>>>>>> needs to be tested but my turn out to be a non-issue.
>>>>>>
>>>>>>
>>>>>> I think these 4 issues need to be resolved before there is a pool2 or
>>>>>> dbcp2 release.
>>>>>>
>>>>>>
>>>>>> Assuming there are no objections, I plan to start committing along these
>>>>>> lines in the next couple of days.
>>>>>>
>>>>>> Mark
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>
>>>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [DBCP] The plan for v2
Posted by Gary Gregory <ga...@gmail.com>.
On Apr 23, 2011, at 18:43, Phil Steitz <ph...@gmail.com> wrote:
> On 4/23/11 2:24 PM, Gary Gregory wrote:
>> I'd like to think this reset should let us get to see a release with
>> generics sooner rather than later. I'm all for releasing early for
>> generics and moving on from three.
> We need to make whatever other API changes we are going to make for
> the foreseeable future in 2.0 before cutting a 2.0 release. There
> are also quite a few issues requiring behavior change / definition
> that we need to resolve for 2.0. Just "generifying" is not enough.
> We need to think carefully about the 2.0 APIs for [pool] and [dbcp]
> - both syntax and semantics. Given the extent of reuse of these
> components, we can't afford to repeatedly break compatibility.
>
> Phil
Sounds good but that's a lengthy process. Would it be possible to
generify in the 1.x world. In a 1.6 for example?
Gary
>> Gary
>>
>> On Apr 23, 2011, at 12:14, Phil Steitz <ph...@gmail.com> wrote:
>>
>>> On 4/23/11 8:07 AM, Simone Tripodi wrote:
>>>> GREAT, thanks Phil!!!
>>>> I'm going to checkout the current trunk and updating pool code!!!
>>>> Have a nice weekend!!!
>>>> Simo
>>> Great! Remember to update changes.xml in trunk with references to
>>> issues as you bring things over. For now, let's just make the
>>> generification changes (i.e., hold off on property name and
>>> mutability changes). I will start working on dbcp, first attacking
>>> the real issues against 1.x and then getting compilation against the
>>> new pool to work in trunk.
>>>
>>> Phil
>>>> http://people.apache.org/~simonetripodi/
>>>> http://www.99soft.org/
>>>>
>>>>
>>>>
>>>> On Sat, Apr 23, 2011 at 5:04 PM, Phil Steitz <ph...@gmail.com> wrote:
>>>>> On 3/22/11 11:20 AM, Mark Thomas wrote:
>>>>>> On 22/03/2011 17:58, Gary Gregory wrote:
>>>>>>> Hi Mark and all:
>>>>>>>
>>>>>>> It's good to hear someone is thinking about moving forward!
>>>>>>>
>>>>>>> pool2 trunk seems to me to be highly volatile based on having worked some in
>>>>>>> pool2.
>>>>>>>
>>>>>>> I've read opinions here going back and forth as to how to solidify the API
>>>>>>> or even go /back/ to the pool1 style before moving forward again.
>>>>>>>
>>>>>>> I think time would be better spent solidifying pool2. Time spent matching
>>>>>>> dbcp2 to pool2 could be a waste because, to me, pool2 feels like a moving
>>>>>>> target ATM.
>>>>>> pool2 is a moving target because a lot of the re-factoring has been an
>>>>>> academic exercise. Having a clear end user for this (Tomcat -> DBCP ->
>>>>>> POOL) should provide the direction necessary to solidify pool2. I don't
>>>>>> mind working with a moving target as long as it is moving towards a
>>>>>> clear goal. That goal for me is:
>>>>>> - Java 5 / generics
>>>>>> - fixing inconsistencies / oddities
>>>>>> - improved performance on DBCP in multi-core servers.
>>>>>>
>>>>>> It would certainly make starting dbcp2 a whole lot easier if most of the
>>>>>> pool2 re-factoring had not taken place. I think we made a mistake in not
>>>>>> pushing forward with DBCP and POOL in parallel. That said, I like a lot
>>>>>> of the pool2 changes and don't want to throw them away.
>>>>>>
>>>>>> What do folks think to the following:
>>>>>> - move pool trunk to a POOL_FUTURE branch
>>>>>> - restore pool trunk to a copy of the POOL_1_X branch
>>>>> Done.
>>>>>
>>>>> Phil
>>>>>> - rename pool package to o.a.c.pool2
>>>>>> (in reality this would probably be a merge from POOL_FUTURE)
>>>>>> - rename dbcp packages to o.a.c.dbcp2
>>>>>> - get pool2 and dbcp2 working together
>>>>>> - get Tomcat trunk working with dbcp2
>>>>>> - go through the POOL_FUTURE changes one at a time:
>>>>>> - merging it into pool2 trunk
>>>>>> - updating dbcp2 trunk if necessary
>>>>>> - testing updated dbcp2 with Tomcat
>>>>>> - if a POOL_FUTURE change breaks DBCP/Tomcat integration in a way that
>>>>>> can't easily be fixed skip that change and leave it in POOL_FUTURE
>>>>>>
>>>>>> Mark
>>>>>>
>>>>>>> Min Java 5: +1!
>>>>>>>
>>>>>>> Gary
>>>>>>>
>>>>>>> On Tue, Mar 22, 2011 at 1:46 PM, Mark Thomas <ma...@apache.org> wrote:
>>>>>>>
>>>>>>>> Don't let the title get your hopes up. I don't have one yet, at least
>>>>>>>> not a complete one.
>>>>>>>> One of the primary driver for pool2 was to make use of
>>>>>>>> java.util.concurrent for the pool implementation and significantly
>>>>>>>> improve DBCP performance on multi-core systems (re-using ideas where we
>>>>>>>> can from Tomcat's jdbc-pool). I'm at the point where I have some time to
>>>>>>>> work on this.
>>>>>>>>
>>>>>>>> My very outline plan was as follows:
>>>>>>>> a) get DBCP working with pool2
>>>>>>>> b) run the jdbc-pool performance tests to see how much ground we need to
>>>>>>>> catch up
>>>>>>>> c) improve the pool2 implementation until we get somewhere close to
>>>>>>>> jdbc-pool
>>>>>>>>
>>>>>>>> a) is non-trival and is really the focus of this e-mail.
>>>>>>>>
>>>>>>>> Issue 1
>>>>>>>> =======
>>>>>>>> DBCP isn't going to be able to use pool2 without some major re-factoring.
>>>>>>>>
>>>>>>>> My solution is:
>>>>>>>> - copy current dbcp trunk to a branch
>>>>>>>> - rename o.a.commons.dbcp to o.a.commons.dbcp2
>>>>>>>> - update dependencies from pool to pool2
>>>>>>>> - get it working
>>>>>>>>
>>>>>>>> Issue 2
>>>>>>>> =======
>>>>>>>> DBCP also ships with the o.a.commons.jocl package.
>>>>>>>>
>>>>>>>> There have been no jocl related questions on the users list since 2007.
>>>>>>>> To prevent clashes between dbcp1 and dbcp2 I propose to simply drop JOCL
>>>>>>>> support in dbcp2.
>>>>>>>>
>>>>>>>> Issue 3
>>>>>>>> =======
>>>>>>>> Minimum Java version.
>>>>>>>>
>>>>>>>> Supporting multiple JDBC API versions is a nuisance. I propose switching
>>>>>>>> to a jdbc-pool style proxy approach. I also propose a minimum Java
>>>>>>>> version of 5 to align with pool2.
>>>>>>>>
>>>>>>>> Issue 4
>>>>>>>> =======
>>>>>>>> Will the new dbcp work with Servlet containers?
>>>>>>>>
>>>>>>>> There were some concerns in this area with the pool2 re-factoring. This
>>>>>>>> needs to be tested but my turn out to be a non-issue.
>>>>>>>>
>>>>>>>>
>>>>>>>> I think these 4 issues need to be resolved before there is a pool2 or
>>>>>>>> dbcp2 release.
>>>>>>>>
>>>>>>>>
>>>>>>>> Assuming there are no objections, I plan to start committing along these
>>>>>>>> lines in the next couple of days.
>>>>>>>>
>>>>>>>> Mark
>>>>>>>>
>>>>>>>> ---------------------------------------------------------------------
>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>>>
>>>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>
>>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>
>>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [DBCP] The plan for v2
Posted by Phil Steitz <ph...@gmail.com>.
On 4/23/11 2:24 PM, Gary Gregory wrote:
> I'd like to think this reset should let us get to see a release with
> generics sooner rather than later. I'm all for releasing early for
> generics and moving on from three.
We need to make whatever other API changes we are going to make for
the foreseeable future in 2.0 before cutting a 2.0 release. There
are also quite a few issues requiring behavior change / definition
that we need to resolve for 2.0. Just "generifying" is not enough.
We need to think carefully about the 2.0 APIs for [pool] and [dbcp]
- both syntax and semantics. Given the extent of reuse of these
components, we can't afford to repeatedly break compatibility.
Phil
> Gary
>
> On Apr 23, 2011, at 12:14, Phil Steitz <ph...@gmail.com> wrote:
>
>> On 4/23/11 8:07 AM, Simone Tripodi wrote:
>>> GREAT, thanks Phil!!!
>>> I'm going to checkout the current trunk and updating pool code!!!
>>> Have a nice weekend!!!
>>> Simo
>> Great! Remember to update changes.xml in trunk with references to
>> issues as you bring things over. For now, let's just make the
>> generification changes (i.e., hold off on property name and
>> mutability changes). I will start working on dbcp, first attacking
>> the real issues against 1.x and then getting compilation against the
>> new pool to work in trunk.
>>
>> Phil
>>> http://people.apache.org/~simonetripodi/
>>> http://www.99soft.org/
>>>
>>>
>>>
>>> On Sat, Apr 23, 2011 at 5:04 PM, Phil Steitz <ph...@gmail.com> wrote:
>>>> On 3/22/11 11:20 AM, Mark Thomas wrote:
>>>>> On 22/03/2011 17:58, Gary Gregory wrote:
>>>>>> Hi Mark and all:
>>>>>>
>>>>>> It's good to hear someone is thinking about moving forward!
>>>>>>
>>>>>> pool2 trunk seems to me to be highly volatile based on having worked some in
>>>>>> pool2.
>>>>>>
>>>>>> I've read opinions here going back and forth as to how to solidify the API
>>>>>> or even go /back/ to the pool1 style before moving forward again.
>>>>>>
>>>>>> I think time would be better spent solidifying pool2. Time spent matching
>>>>>> dbcp2 to pool2 could be a waste because, to me, pool2 feels like a moving
>>>>>> target ATM.
>>>>> pool2 is a moving target because a lot of the re-factoring has been an
>>>>> academic exercise. Having a clear end user for this (Tomcat -> DBCP ->
>>>>> POOL) should provide the direction necessary to solidify pool2. I don't
>>>>> mind working with a moving target as long as it is moving towards a
>>>>> clear goal. That goal for me is:
>>>>> - Java 5 / generics
>>>>> - fixing inconsistencies / oddities
>>>>> - improved performance on DBCP in multi-core servers.
>>>>>
>>>>> It would certainly make starting dbcp2 a whole lot easier if most of the
>>>>> pool2 re-factoring had not taken place. I think we made a mistake in not
>>>>> pushing forward with DBCP and POOL in parallel. That said, I like a lot
>>>>> of the pool2 changes and don't want to throw them away.
>>>>>
>>>>> What do folks think to the following:
>>>>> - move pool trunk to a POOL_FUTURE branch
>>>>> - restore pool trunk to a copy of the POOL_1_X branch
>>>> Done.
>>>>
>>>> Phil
>>>>> - rename pool package to o.a.c.pool2
>>>>> (in reality this would probably be a merge from POOL_FUTURE)
>>>>> - rename dbcp packages to o.a.c.dbcp2
>>>>> - get pool2 and dbcp2 working together
>>>>> - get Tomcat trunk working with dbcp2
>>>>> - go through the POOL_FUTURE changes one at a time:
>>>>> - merging it into pool2 trunk
>>>>> - updating dbcp2 trunk if necessary
>>>>> - testing updated dbcp2 with Tomcat
>>>>> - if a POOL_FUTURE change breaks DBCP/Tomcat integration in a way that
>>>>> can't easily be fixed skip that change and leave it in POOL_FUTURE
>>>>>
>>>>> Mark
>>>>>
>>>>>> Min Java 5: +1!
>>>>>>
>>>>>> Gary
>>>>>>
>>>>>> On Tue, Mar 22, 2011 at 1:46 PM, Mark Thomas <ma...@apache.org> wrote:
>>>>>>
>>>>>>> Don't let the title get your hopes up. I don't have one yet, at least
>>>>>>> not a complete one.
>>>>>>> One of the primary driver for pool2 was to make use of
>>>>>>> java.util.concurrent for the pool implementation and significantly
>>>>>>> improve DBCP performance on multi-core systems (re-using ideas where we
>>>>>>> can from Tomcat's jdbc-pool). I'm at the point where I have some time to
>>>>>>> work on this.
>>>>>>>
>>>>>>> My very outline plan was as follows:
>>>>>>> a) get DBCP working with pool2
>>>>>>> b) run the jdbc-pool performance tests to see how much ground we need to
>>>>>>> catch up
>>>>>>> c) improve the pool2 implementation until we get somewhere close to
>>>>>>> jdbc-pool
>>>>>>>
>>>>>>> a) is non-trival and is really the focus of this e-mail.
>>>>>>>
>>>>>>> Issue 1
>>>>>>> =======
>>>>>>> DBCP isn't going to be able to use pool2 without some major re-factoring.
>>>>>>>
>>>>>>> My solution is:
>>>>>>> - copy current dbcp trunk to a branch
>>>>>>> - rename o.a.commons.dbcp to o.a.commons.dbcp2
>>>>>>> - update dependencies from pool to pool2
>>>>>>> - get it working
>>>>>>>
>>>>>>> Issue 2
>>>>>>> =======
>>>>>>> DBCP also ships with the o.a.commons.jocl package.
>>>>>>>
>>>>>>> There have been no jocl related questions on the users list since 2007.
>>>>>>> To prevent clashes between dbcp1 and dbcp2 I propose to simply drop JOCL
>>>>>>> support in dbcp2.
>>>>>>>
>>>>>>> Issue 3
>>>>>>> =======
>>>>>>> Minimum Java version.
>>>>>>>
>>>>>>> Supporting multiple JDBC API versions is a nuisance. I propose switching
>>>>>>> to a jdbc-pool style proxy approach. I also propose a minimum Java
>>>>>>> version of 5 to align with pool2.
>>>>>>>
>>>>>>> Issue 4
>>>>>>> =======
>>>>>>> Will the new dbcp work with Servlet containers?
>>>>>>>
>>>>>>> There were some concerns in this area with the pool2 re-factoring. This
>>>>>>> needs to be tested but my turn out to be a non-issue.
>>>>>>>
>>>>>>>
>>>>>>> I think these 4 issues need to be resolved before there is a pool2 or
>>>>>>> dbcp2 release.
>>>>>>>
>>>>>>>
>>>>>>> Assuming there are no objections, I plan to start committing along these
>>>>>>> lines in the next couple of days.
>>>>>>>
>>>>>>> Mark
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>>
>>>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>
>>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>
>>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [DBCP] The plan for v2
Posted by Simone Tripodi <si...@apache.org>.
Hi Gary,
my strong +1 on this, that's way we agreed on resetting the trunk (and
I started working to restore generics :P)
Thanks for your feedback!!!
Simo
http://people.apache.org/~simonetripodi/
http://www.99soft.org/
On Sat, Apr 23, 2011 at 11:24 PM, Gary Gregory <ga...@gmail.com> wrote:
> I'd like to think this reset should let us get to see a release with
> generics sooner rather than later. I'm all for releasing early for
> generics and moving on from three.
>
> Gary
>
> On Apr 23, 2011, at 12:14, Phil Steitz <ph...@gmail.com> wrote:
>
>> On 4/23/11 8:07 AM, Simone Tripodi wrote:
>>> GREAT, thanks Phil!!!
>>> I'm going to checkout the current trunk and updating pool code!!!
>>> Have a nice weekend!!!
>>> Simo
>>
>> Great! Remember to update changes.xml in trunk with references to
>> issues as you bring things over. For now, let's just make the
>> generification changes (i.e., hold off on property name and
>> mutability changes). I will start working on dbcp, first attacking
>> the real issues against 1.x and then getting compilation against the
>> new pool to work in trunk.
>>
>> Phil
>>> http://people.apache.org/~simonetripodi/
>>> http://www.99soft.org/
>>>
>>>
>>>
>>> On Sat, Apr 23, 2011 at 5:04 PM, Phil Steitz <ph...@gmail.com> wrote:
>>>> On 3/22/11 11:20 AM, Mark Thomas wrote:
>>>>> On 22/03/2011 17:58, Gary Gregory wrote:
>>>>>> Hi Mark and all:
>>>>>>
>>>>>> It's good to hear someone is thinking about moving forward!
>>>>>>
>>>>>> pool2 trunk seems to me to be highly volatile based on having worked some in
>>>>>> pool2.
>>>>>>
>>>>>> I've read opinions here going back and forth as to how to solidify the API
>>>>>> or even go /back/ to the pool1 style before moving forward again.
>>>>>>
>>>>>> I think time would be better spent solidifying pool2. Time spent matching
>>>>>> dbcp2 to pool2 could be a waste because, to me, pool2 feels like a moving
>>>>>> target ATM.
>>>>> pool2 is a moving target because a lot of the re-factoring has been an
>>>>> academic exercise. Having a clear end user for this (Tomcat -> DBCP ->
>>>>> POOL) should provide the direction necessary to solidify pool2. I don't
>>>>> mind working with a moving target as long as it is moving towards a
>>>>> clear goal. That goal for me is:
>>>>> - Java 5 / generics
>>>>> - fixing inconsistencies / oddities
>>>>> - improved performance on DBCP in multi-core servers.
>>>>>
>>>>> It would certainly make starting dbcp2 a whole lot easier if most of the
>>>>> pool2 re-factoring had not taken place. I think we made a mistake in not
>>>>> pushing forward with DBCP and POOL in parallel. That said, I like a lot
>>>>> of the pool2 changes and don't want to throw them away.
>>>>>
>>>>> What do folks think to the following:
>>>>> - move pool trunk to a POOL_FUTURE branch
>>>>> - restore pool trunk to a copy of the POOL_1_X branch
>>>> Done.
>>>>
>>>> Phil
>>>>> - rename pool package to o.a.c.pool2
>>>>> (in reality this would probably be a merge from POOL_FUTURE)
>>>>> - rename dbcp packages to o.a.c.dbcp2
>>>>> - get pool2 and dbcp2 working together
>>>>> - get Tomcat trunk working with dbcp2
>>>>> - go through the POOL_FUTURE changes one at a time:
>>>>> - merging it into pool2 trunk
>>>>> - updating dbcp2 trunk if necessary
>>>>> - testing updated dbcp2 with Tomcat
>>>>> - if a POOL_FUTURE change breaks DBCP/Tomcat integration in a way that
>>>>> can't easily be fixed skip that change and leave it in POOL_FUTURE
>>>>>
>>>>> Mark
>>>>>
>>>>>> Min Java 5: +1!
>>>>>>
>>>>>> Gary
>>>>>>
>>>>>> On Tue, Mar 22, 2011 at 1:46 PM, Mark Thomas <ma...@apache.org> wrote:
>>>>>>
>>>>>>> Don't let the title get your hopes up. I don't have one yet, at least
>>>>>>> not a complete one.
>>>>>>> One of the primary driver for pool2 was to make use of
>>>>>>> java.util.concurrent for the pool implementation and significantly
>>>>>>> improve DBCP performance on multi-core systems (re-using ideas where we
>>>>>>> can from Tomcat's jdbc-pool). I'm at the point where I have some time to
>>>>>>> work on this.
>>>>>>>
>>>>>>> My very outline plan was as follows:
>>>>>>> a) get DBCP working with pool2
>>>>>>> b) run the jdbc-pool performance tests to see how much ground we need to
>>>>>>> catch up
>>>>>>> c) improve the pool2 implementation until we get somewhere close to
>>>>>>> jdbc-pool
>>>>>>>
>>>>>>> a) is non-trival and is really the focus of this e-mail.
>>>>>>>
>>>>>>> Issue 1
>>>>>>> =======
>>>>>>> DBCP isn't going to be able to use pool2 without some major re-factoring.
>>>>>>>
>>>>>>> My solution is:
>>>>>>> - copy current dbcp trunk to a branch
>>>>>>> - rename o.a.commons.dbcp to o.a.commons.dbcp2
>>>>>>> - update dependencies from pool to pool2
>>>>>>> - get it working
>>>>>>>
>>>>>>> Issue 2
>>>>>>> =======
>>>>>>> DBCP also ships with the o.a.commons.jocl package.
>>>>>>>
>>>>>>> There have been no jocl related questions on the users list since 2007.
>>>>>>> To prevent clashes between dbcp1 and dbcp2 I propose to simply drop JOCL
>>>>>>> support in dbcp2.
>>>>>>>
>>>>>>> Issue 3
>>>>>>> =======
>>>>>>> Minimum Java version.
>>>>>>>
>>>>>>> Supporting multiple JDBC API versions is a nuisance. I propose switching
>>>>>>> to a jdbc-pool style proxy approach. I also propose a minimum Java
>>>>>>> version of 5 to align with pool2.
>>>>>>>
>>>>>>> Issue 4
>>>>>>> =======
>>>>>>> Will the new dbcp work with Servlet containers?
>>>>>>>
>>>>>>> There were some concerns in this area with the pool2 re-factoring. This
>>>>>>> needs to be tested but my turn out to be a non-issue.
>>>>>>>
>>>>>>>
>>>>>>> I think these 4 issues need to be resolved before there is a pool2 or
>>>>>>> dbcp2 release.
>>>>>>>
>>>>>>>
>>>>>>> Assuming there are no objections, I plan to start committing along these
>>>>>>> lines in the next couple of days.
>>>>>>>
>>>>>>> Mark
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>>
>>>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>
>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>
>>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [DBCP] The plan for v2
Posted by Gary Gregory <ga...@gmail.com>.
I'd like to think this reset should let us get to see a release with
generics sooner rather than later. I'm all for releasing early for
generics and moving on from three.
Gary
On Apr 23, 2011, at 12:14, Phil Steitz <ph...@gmail.com> wrote:
> On 4/23/11 8:07 AM, Simone Tripodi wrote:
>> GREAT, thanks Phil!!!
>> I'm going to checkout the current trunk and updating pool code!!!
>> Have a nice weekend!!!
>> Simo
>
> Great! Remember to update changes.xml in trunk with references to
> issues as you bring things over. For now, let's just make the
> generification changes (i.e., hold off on property name and
> mutability changes). I will start working on dbcp, first attacking
> the real issues against 1.x and then getting compilation against the
> new pool to work in trunk.
>
> Phil
>> http://people.apache.org/~simonetripodi/
>> http://www.99soft.org/
>>
>>
>>
>> On Sat, Apr 23, 2011 at 5:04 PM, Phil Steitz <ph...@gmail.com> wrote:
>>> On 3/22/11 11:20 AM, Mark Thomas wrote:
>>>> On 22/03/2011 17:58, Gary Gregory wrote:
>>>>> Hi Mark and all:
>>>>>
>>>>> It's good to hear someone is thinking about moving forward!
>>>>>
>>>>> pool2 trunk seems to me to be highly volatile based on having worked some in
>>>>> pool2.
>>>>>
>>>>> I've read opinions here going back and forth as to how to solidify the API
>>>>> or even go /back/ to the pool1 style before moving forward again.
>>>>>
>>>>> I think time would be better spent solidifying pool2. Time spent matching
>>>>> dbcp2 to pool2 could be a waste because, to me, pool2 feels like a moving
>>>>> target ATM.
>>>> pool2 is a moving target because a lot of the re-factoring has been an
>>>> academic exercise. Having a clear end user for this (Tomcat -> DBCP ->
>>>> POOL) should provide the direction necessary to solidify pool2. I don't
>>>> mind working with a moving target as long as it is moving towards a
>>>> clear goal. That goal for me is:
>>>> - Java 5 / generics
>>>> - fixing inconsistencies / oddities
>>>> - improved performance on DBCP in multi-core servers.
>>>>
>>>> It would certainly make starting dbcp2 a whole lot easier if most of the
>>>> pool2 re-factoring had not taken place. I think we made a mistake in not
>>>> pushing forward with DBCP and POOL in parallel. That said, I like a lot
>>>> of the pool2 changes and don't want to throw them away.
>>>>
>>>> What do folks think to the following:
>>>> - move pool trunk to a POOL_FUTURE branch
>>>> - restore pool trunk to a copy of the POOL_1_X branch
>>> Done.
>>>
>>> Phil
>>>> - rename pool package to o.a.c.pool2
>>>> (in reality this would probably be a merge from POOL_FUTURE)
>>>> - rename dbcp packages to o.a.c.dbcp2
>>>> - get pool2 and dbcp2 working together
>>>> - get Tomcat trunk working with dbcp2
>>>> - go through the POOL_FUTURE changes one at a time:
>>>> - merging it into pool2 trunk
>>>> - updating dbcp2 trunk if necessary
>>>> - testing updated dbcp2 with Tomcat
>>>> - if a POOL_FUTURE change breaks DBCP/Tomcat integration in a way that
>>>> can't easily be fixed skip that change and leave it in POOL_FUTURE
>>>>
>>>> Mark
>>>>
>>>>> Min Java 5: +1!
>>>>>
>>>>> Gary
>>>>>
>>>>> On Tue, Mar 22, 2011 at 1:46 PM, Mark Thomas <ma...@apache.org> wrote:
>>>>>
>>>>>> Don't let the title get your hopes up. I don't have one yet, at least
>>>>>> not a complete one.
>>>>>> One of the primary driver for pool2 was to make use of
>>>>>> java.util.concurrent for the pool implementation and significantly
>>>>>> improve DBCP performance on multi-core systems (re-using ideas where we
>>>>>> can from Tomcat's jdbc-pool). I'm at the point where I have some time to
>>>>>> work on this.
>>>>>>
>>>>>> My very outline plan was as follows:
>>>>>> a) get DBCP working with pool2
>>>>>> b) run the jdbc-pool performance tests to see how much ground we need to
>>>>>> catch up
>>>>>> c) improve the pool2 implementation until we get somewhere close to
>>>>>> jdbc-pool
>>>>>>
>>>>>> a) is non-trival and is really the focus of this e-mail.
>>>>>>
>>>>>> Issue 1
>>>>>> =======
>>>>>> DBCP isn't going to be able to use pool2 without some major re-factoring.
>>>>>>
>>>>>> My solution is:
>>>>>> - copy current dbcp trunk to a branch
>>>>>> - rename o.a.commons.dbcp to o.a.commons.dbcp2
>>>>>> - update dependencies from pool to pool2
>>>>>> - get it working
>>>>>>
>>>>>> Issue 2
>>>>>> =======
>>>>>> DBCP also ships with the o.a.commons.jocl package.
>>>>>>
>>>>>> There have been no jocl related questions on the users list since 2007.
>>>>>> To prevent clashes between dbcp1 and dbcp2 I propose to simply drop JOCL
>>>>>> support in dbcp2.
>>>>>>
>>>>>> Issue 3
>>>>>> =======
>>>>>> Minimum Java version.
>>>>>>
>>>>>> Supporting multiple JDBC API versions is a nuisance. I propose switching
>>>>>> to a jdbc-pool style proxy approach. I also propose a minimum Java
>>>>>> version of 5 to align with pool2.
>>>>>>
>>>>>> Issue 4
>>>>>> =======
>>>>>> Will the new dbcp work with Servlet containers?
>>>>>>
>>>>>> There were some concerns in this area with the pool2 re-factoring. This
>>>>>> needs to be tested but my turn out to be a non-issue.
>>>>>>
>>>>>>
>>>>>> I think these 4 issues need to be resolved before there is a pool2 or
>>>>>> dbcp2 release.
>>>>>>
>>>>>>
>>>>>> Assuming there are no objections, I plan to start committing along these
>>>>>> lines in the next couple of days.
>>>>>>
>>>>>> Mark
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>
>>>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [DBCP] The plan for v2
Posted by Phil Steitz <ph...@gmail.com>.
On 4/23/11 8:07 AM, Simone Tripodi wrote:
> GREAT, thanks Phil!!!
> I'm going to checkout the current trunk and updating pool code!!!
> Have a nice weekend!!!
> Simo
Great! Remember to update changes.xml in trunk with references to
issues as you bring things over. For now, let's just make the
generification changes (i.e., hold off on property name and
mutability changes). I will start working on dbcp, first attacking
the real issues against 1.x and then getting compilation against the
new pool to work in trunk.
Phil
> http://people.apache.org/~simonetripodi/
> http://www.99soft.org/
>
>
>
> On Sat, Apr 23, 2011 at 5:04 PM, Phil Steitz <ph...@gmail.com> wrote:
>> On 3/22/11 11:20 AM, Mark Thomas wrote:
>>> On 22/03/2011 17:58, Gary Gregory wrote:
>>>> Hi Mark and all:
>>>>
>>>> It's good to hear someone is thinking about moving forward!
>>>>
>>>> pool2 trunk seems to me to be highly volatile based on having worked some in
>>>> pool2.
>>>>
>>>> I've read opinions here going back and forth as to how to solidify the API
>>>> or even go /back/ to the pool1 style before moving forward again.
>>>>
>>>> I think time would be better spent solidifying pool2. Time spent matching
>>>> dbcp2 to pool2 could be a waste because, to me, pool2 feels like a moving
>>>> target ATM.
>>> pool2 is a moving target because a lot of the re-factoring has been an
>>> academic exercise. Having a clear end user for this (Tomcat -> DBCP ->
>>> POOL) should provide the direction necessary to solidify pool2. I don't
>>> mind working with a moving target as long as it is moving towards a
>>> clear goal. That goal for me is:
>>> - Java 5 / generics
>>> - fixing inconsistencies / oddities
>>> - improved performance on DBCP in multi-core servers.
>>>
>>> It would certainly make starting dbcp2 a whole lot easier if most of the
>>> pool2 re-factoring had not taken place. I think we made a mistake in not
>>> pushing forward with DBCP and POOL in parallel. That said, I like a lot
>>> of the pool2 changes and don't want to throw them away.
>>>
>>> What do folks think to the following:
>>> - move pool trunk to a POOL_FUTURE branch
>>> - restore pool trunk to a copy of the POOL_1_X branch
>> Done.
>>
>> Phil
>>> - rename pool package to o.a.c.pool2
>>> (in reality this would probably be a merge from POOL_FUTURE)
>>> - rename dbcp packages to o.a.c.dbcp2
>>> - get pool2 and dbcp2 working together
>>> - get Tomcat trunk working with dbcp2
>>> - go through the POOL_FUTURE changes one at a time:
>>> - merging it into pool2 trunk
>>> - updating dbcp2 trunk if necessary
>>> - testing updated dbcp2 with Tomcat
>>> - if a POOL_FUTURE change breaks DBCP/Tomcat integration in a way that
>>> can't easily be fixed skip that change and leave it in POOL_FUTURE
>>>
>>> Mark
>>>
>>>> Min Java 5: +1!
>>>>
>>>> Gary
>>>>
>>>> On Tue, Mar 22, 2011 at 1:46 PM, Mark Thomas <ma...@apache.org> wrote:
>>>>
>>>>> Don't let the title get your hopes up. I don't have one yet, at least
>>>>> not a complete one.
>>>>> One of the primary driver for pool2 was to make use of
>>>>> java.util.concurrent for the pool implementation and significantly
>>>>> improve DBCP performance on multi-core systems (re-using ideas where we
>>>>> can from Tomcat's jdbc-pool). I'm at the point where I have some time to
>>>>> work on this.
>>>>>
>>>>> My very outline plan was as follows:
>>>>> a) get DBCP working with pool2
>>>>> b) run the jdbc-pool performance tests to see how much ground we need to
>>>>> catch up
>>>>> c) improve the pool2 implementation until we get somewhere close to
>>>>> jdbc-pool
>>>>>
>>>>> a) is non-trival and is really the focus of this e-mail.
>>>>>
>>>>> Issue 1
>>>>> =======
>>>>> DBCP isn't going to be able to use pool2 without some major re-factoring.
>>>>>
>>>>> My solution is:
>>>>> - copy current dbcp trunk to a branch
>>>>> - rename o.a.commons.dbcp to o.a.commons.dbcp2
>>>>> - update dependencies from pool to pool2
>>>>> - get it working
>>>>>
>>>>> Issue 2
>>>>> =======
>>>>> DBCP also ships with the o.a.commons.jocl package.
>>>>>
>>>>> There have been no jocl related questions on the users list since 2007.
>>>>> To prevent clashes between dbcp1 and dbcp2 I propose to simply drop JOCL
>>>>> support in dbcp2.
>>>>>
>>>>> Issue 3
>>>>> =======
>>>>> Minimum Java version.
>>>>>
>>>>> Supporting multiple JDBC API versions is a nuisance. I propose switching
>>>>> to a jdbc-pool style proxy approach. I also propose a minimum Java
>>>>> version of 5 to align with pool2.
>>>>>
>>>>> Issue 4
>>>>> =======
>>>>> Will the new dbcp work with Servlet containers?
>>>>>
>>>>> There were some concerns in this area with the pool2 re-factoring. This
>>>>> needs to be tested but my turn out to be a non-issue.
>>>>>
>>>>>
>>>>> I think these 4 issues need to be resolved before there is a pool2 or
>>>>> dbcp2 release.
>>>>>
>>>>>
>>>>> Assuming there are no objections, I plan to start committing along these
>>>>> lines in the next couple of days.
>>>>>
>>>>> Mark
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>
>>>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [DBCP] The plan for v2
Posted by Simone Tripodi <si...@apache.org>.
GREAT, thanks Phil!!!
I'm going to checkout the current trunk and updating pool code!!!
Have a nice weekend!!!
Simo
http://people.apache.org/~simonetripodi/
http://www.99soft.org/
On Sat, Apr 23, 2011 at 5:04 PM, Phil Steitz <ph...@gmail.com> wrote:
> On 3/22/11 11:20 AM, Mark Thomas wrote:
>> On 22/03/2011 17:58, Gary Gregory wrote:
>>> Hi Mark and all:
>>>
>>> It's good to hear someone is thinking about moving forward!
>>>
>>> pool2 trunk seems to me to be highly volatile based on having worked some in
>>> pool2.
>>>
>>> I've read opinions here going back and forth as to how to solidify the API
>>> or even go /back/ to the pool1 style before moving forward again.
>>>
>>> I think time would be better spent solidifying pool2. Time spent matching
>>> dbcp2 to pool2 could be a waste because, to me, pool2 feels like a moving
>>> target ATM.
>> pool2 is a moving target because a lot of the re-factoring has been an
>> academic exercise. Having a clear end user for this (Tomcat -> DBCP ->
>> POOL) should provide the direction necessary to solidify pool2. I don't
>> mind working with a moving target as long as it is moving towards a
>> clear goal. That goal for me is:
>> - Java 5 / generics
>> - fixing inconsistencies / oddities
>> - improved performance on DBCP in multi-core servers.
>>
>> It would certainly make starting dbcp2 a whole lot easier if most of the
>> pool2 re-factoring had not taken place. I think we made a mistake in not
>> pushing forward with DBCP and POOL in parallel. That said, I like a lot
>> of the pool2 changes and don't want to throw them away.
>>
>> What do folks think to the following:
>> - move pool trunk to a POOL_FUTURE branch
>> - restore pool trunk to a copy of the POOL_1_X branch
> Done.
>
> Phil
>> - rename pool package to o.a.c.pool2
>> (in reality this would probably be a merge from POOL_FUTURE)
>> - rename dbcp packages to o.a.c.dbcp2
>> - get pool2 and dbcp2 working together
>> - get Tomcat trunk working with dbcp2
>> - go through the POOL_FUTURE changes one at a time:
>> - merging it into pool2 trunk
>> - updating dbcp2 trunk if necessary
>> - testing updated dbcp2 with Tomcat
>> - if a POOL_FUTURE change breaks DBCP/Tomcat integration in a way that
>> can't easily be fixed skip that change and leave it in POOL_FUTURE
>>
>> Mark
>>
>>> Min Java 5: +1!
>>>
>>> Gary
>>>
>>> On Tue, Mar 22, 2011 at 1:46 PM, Mark Thomas <ma...@apache.org> wrote:
>>>
>>>> Don't let the title get your hopes up. I don't have one yet, at least
>>>> not a complete one.
>>>> One of the primary driver for pool2 was to make use of
>>>> java.util.concurrent for the pool implementation and significantly
>>>> improve DBCP performance on multi-core systems (re-using ideas where we
>>>> can from Tomcat's jdbc-pool). I'm at the point where I have some time to
>>>> work on this.
>>>>
>>>> My very outline plan was as follows:
>>>> a) get DBCP working with pool2
>>>> b) run the jdbc-pool performance tests to see how much ground we need to
>>>> catch up
>>>> c) improve the pool2 implementation until we get somewhere close to
>>>> jdbc-pool
>>>>
>>>> a) is non-trival and is really the focus of this e-mail.
>>>>
>>>> Issue 1
>>>> =======
>>>> DBCP isn't going to be able to use pool2 without some major re-factoring.
>>>>
>>>> My solution is:
>>>> - copy current dbcp trunk to a branch
>>>> - rename o.a.commons.dbcp to o.a.commons.dbcp2
>>>> - update dependencies from pool to pool2
>>>> - get it working
>>>>
>>>> Issue 2
>>>> =======
>>>> DBCP also ships with the o.a.commons.jocl package.
>>>>
>>>> There have been no jocl related questions on the users list since 2007.
>>>> To prevent clashes between dbcp1 and dbcp2 I propose to simply drop JOCL
>>>> support in dbcp2.
>>>>
>>>> Issue 3
>>>> =======
>>>> Minimum Java version.
>>>>
>>>> Supporting multiple JDBC API versions is a nuisance. I propose switching
>>>> to a jdbc-pool style proxy approach. I also propose a minimum Java
>>>> version of 5 to align with pool2.
>>>>
>>>> Issue 4
>>>> =======
>>>> Will the new dbcp work with Servlet containers?
>>>>
>>>> There were some concerns in this area with the pool2 re-factoring. This
>>>> needs to be tested but my turn out to be a non-issue.
>>>>
>>>>
>>>> I think these 4 issues need to be resolved before there is a pool2 or
>>>> dbcp2 release.
>>>>
>>>>
>>>> Assuming there are no objections, I plan to start committing along these
>>>> lines in the next couple of days.
>>>>
>>>> Mark
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>
>>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [DBCP] The plan for v2
Posted by Phil Steitz <ph...@gmail.com>.
On 3/22/11 11:20 AM, Mark Thomas wrote:
> On 22/03/2011 17:58, Gary Gregory wrote:
>> Hi Mark and all:
>>
>> It's good to hear someone is thinking about moving forward!
>>
>> pool2 trunk seems to me to be highly volatile based on having worked some in
>> pool2.
>>
>> I've read opinions here going back and forth as to how to solidify the API
>> or even go /back/ to the pool1 style before moving forward again.
>>
>> I think time would be better spent solidifying pool2. Time spent matching
>> dbcp2 to pool2 could be a waste because, to me, pool2 feels like a moving
>> target ATM.
> pool2 is a moving target because a lot of the re-factoring has been an
> academic exercise. Having a clear end user for this (Tomcat -> DBCP ->
> POOL) should provide the direction necessary to solidify pool2. I don't
> mind working with a moving target as long as it is moving towards a
> clear goal. That goal for me is:
> - Java 5 / generics
> - fixing inconsistencies / oddities
> - improved performance on DBCP in multi-core servers.
>
> It would certainly make starting dbcp2 a whole lot easier if most of the
> pool2 re-factoring had not taken place. I think we made a mistake in not
> pushing forward with DBCP and POOL in parallel. That said, I like a lot
> of the pool2 changes and don't want to throw them away.
>
> What do folks think to the following:
> - move pool trunk to a POOL_FUTURE branch
> - restore pool trunk to a copy of the POOL_1_X branch
Done.
Phil
> - rename pool package to o.a.c.pool2
> (in reality this would probably be a merge from POOL_FUTURE)
> - rename dbcp packages to o.a.c.dbcp2
> - get pool2 and dbcp2 working together
> - get Tomcat trunk working with dbcp2
> - go through the POOL_FUTURE changes one at a time:
> - merging it into pool2 trunk
> - updating dbcp2 trunk if necessary
> - testing updated dbcp2 with Tomcat
> - if a POOL_FUTURE change breaks DBCP/Tomcat integration in a way that
> can't easily be fixed skip that change and leave it in POOL_FUTURE
>
> Mark
>
>> Min Java 5: +1!
>>
>> Gary
>>
>> On Tue, Mar 22, 2011 at 1:46 PM, Mark Thomas <ma...@apache.org> wrote:
>>
>>> Don't let the title get your hopes up. I don't have one yet, at least
>>> not a complete one.
>>> One of the primary driver for pool2 was to make use of
>>> java.util.concurrent for the pool implementation and significantly
>>> improve DBCP performance on multi-core systems (re-using ideas where we
>>> can from Tomcat's jdbc-pool). I'm at the point where I have some time to
>>> work on this.
>>>
>>> My very outline plan was as follows:
>>> a) get DBCP working with pool2
>>> b) run the jdbc-pool performance tests to see how much ground we need to
>>> catch up
>>> c) improve the pool2 implementation until we get somewhere close to
>>> jdbc-pool
>>>
>>> a) is non-trival and is really the focus of this e-mail.
>>>
>>> Issue 1
>>> =======
>>> DBCP isn't going to be able to use pool2 without some major re-factoring.
>>>
>>> My solution is:
>>> - copy current dbcp trunk to a branch
>>> - rename o.a.commons.dbcp to o.a.commons.dbcp2
>>> - update dependencies from pool to pool2
>>> - get it working
>>>
>>> Issue 2
>>> =======
>>> DBCP also ships with the o.a.commons.jocl package.
>>>
>>> There have been no jocl related questions on the users list since 2007.
>>> To prevent clashes between dbcp1 and dbcp2 I propose to simply drop JOCL
>>> support in dbcp2.
>>>
>>> Issue 3
>>> =======
>>> Minimum Java version.
>>>
>>> Supporting multiple JDBC API versions is a nuisance. I propose switching
>>> to a jdbc-pool style proxy approach. I also propose a minimum Java
>>> version of 5 to align with pool2.
>>>
>>> Issue 4
>>> =======
>>> Will the new dbcp work with Servlet containers?
>>>
>>> There were some concerns in this area with the pool2 re-factoring. This
>>> needs to be tested but my turn out to be a non-issue.
>>>
>>>
>>> I think these 4 issues need to be resolved before there is a pool2 or
>>> dbcp2 release.
>>>
>>>
>>> Assuming there are no objections, I plan to start committing along these
>>> lines in the next couple of days.
>>>
>>> Mark
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [DBCP] The plan for v2
Posted by Mark Thomas <ma...@apache.org>.
On 22/03/2011 18:4, Gary Gregory wrote:
> On Tue, Mar 22, 2011 at 2:20 PM, Mark Thomas <ma...@apache.org> wrote:
>
>> What do folks think to the following:
>> - move pool trunk to a POOL_FUTURE branch
>> - restore pool trunk to a copy of the POOL_1_X branch
>> - rename pool package to o.a.c.pool2
>> (in reality this would probably be a merge from POOL_FUTURE)
>
> Why not just use pool2 trunk then? I guess you'll have to try and see.
I started that a few hours ago and my initial impression is that there
would be a lot of work to get dbcp2 working with pool2. It just feels
like much too big a leap. I'm much happier with small incremental changes.
>> - rename dbcp packages to o.a.c.dbcp2
>> - get pool2 and dbcp2 working together
>> - get Tomcat trunk working with dbcp2
>> - go through the POOL_FUTURE changes one at a time:
>> - merging it into pool2 trunk
>> - updating dbcp2 trunk if necessary
>> - testing updated dbcp2 with Tomcat
>> - if a POOL_FUTURE change breaks DBCP/Tomcat integration in a way that
>> can't easily be fixed skip that change and leave it in POOL_FUTURE
>
> I'd hate to see all of the pool2 work tossed aside but I do like the
> evolutionary approach of getting pool2, dbcp2 and Tomcat changing in
> lockstep, one commit at a time. Right it sounds like you are saying that
> pool2 is different enough from pool1 to be a big pain for dbcp2 and Tomcat.
Yes, right now moving to pool2 is a huge obstacle. The intention of my
proposal was to provide a way of keeping most of the POOL_FUTURE changes
whilst allowing incremental changes in dbcp2. svn merge should mean
minimal additional work to merge back POOL_FUTURE changes to pool2
trunk. With luck, we should be able to skip over any problematic
POOL_FUTURE changes and discuss those in more detail before deciding
what to do.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [DBCP] The plan for v2
Posted by Gary Gregory <ga...@gmail.com>.
On Tue, Mar 22, 2011 at 2:20 PM, Mark Thomas <ma...@apache.org> wrote:
> On 22/03/2011 17:58, Gary Gregory wrote:
> > Hi Mark and all:
> >
> > It's good to hear someone is thinking about moving forward!
> >
> > pool2 trunk seems to me to be highly volatile based on having worked some
> in
> > pool2.
> >
> > I've read opinions here going back and forth as to how to solidify the
> API
> > or even go /back/ to the pool1 style before moving forward again.
> >
> > I think time would be better spent solidifying pool2. Time spent matching
> > dbcp2 to pool2 could be a waste because, to me, pool2 feels like a moving
> > target ATM.
>
> pool2 is a moving target because a lot of the re-factoring has been an
> academic exercise. Having a clear end user for this (Tomcat -> DBCP ->
> POOL) should provide the direction necessary to solidify pool2. I don't
> mind working with a moving target as long as it is moving towards a
> clear goal. That goal for me is:
> - Java 5 / generics
>
I would use a generic version of pool1 today!
> - fixing inconsistencies / oddities
>
I tried to address some of that in pool2 but we got bogged down in all sorts
of other issues, including API style. My main concern was the refactoring of
duplicate code.
> - improved performance on DBCP in multi-core servers.
>
> It would certainly make starting dbcp2 a whole lot easier if most of the
> pool2 re-factoring had not taken place. I think we made a mistake in not
> pushing forward with DBCP and POOL in parallel. That said, I like a lot
> of the pool2 changes and don't want to throw them away.
>
> What do folks think to the following:
> - move pool trunk to a POOL_FUTURE branch
> - restore pool trunk to a copy of the POOL_1_X branch
> - rename pool package to o.a.c.pool2
> (in reality this would probably be a merge from POOL_FUTURE)
>
Why not just use pool2 trunk then? I guess you'll have to try and see.
> - rename dbcp packages to o.a.c.dbcp2
> - get pool2 and dbcp2 working together
> - get Tomcat trunk working with dbcp2
> - go through the POOL_FUTURE changes one at a time:
> - merging it into pool2 trunk
> - updating dbcp2 trunk if necessary
> - testing updated dbcp2 with Tomcat
> - if a POOL_FUTURE change breaks DBCP/Tomcat integration in a way that
> can't easily be fixed skip that change and leave it in POOL_FUTURE
>
I'd hate to see all of the pool2 work tossed aside but I do like the
evolutionary approach of getting pool2, dbcp2 and Tomcat changing in
lockstep, one commit at a time. Right it sounds like you are saying that
pool2 is different enough from pool1 to be a big pain for dbcp2 and Tomcat.
Gary
>
> Mark
>
> > Min Java 5: +1!
> >
> > Gary
> >
> > On Tue, Mar 22, 2011 at 1:46 PM, Mark Thomas <ma...@apache.org> wrote:
> >
> >> Don't let the title get your hopes up. I don't have one yet, at least
> >> not a complete one.
> >> One of the primary driver for pool2 was to make use of
> >> java.util.concurrent for the pool implementation and significantly
> >> improve DBCP performance on multi-core systems (re-using ideas where we
> >> can from Tomcat's jdbc-pool). I'm at the point where I have some time to
> >> work on this.
> >>
> >> My very outline plan was as follows:
> >> a) get DBCP working with pool2
> >> b) run the jdbc-pool performance tests to see how much ground we need to
> >> catch up
> >> c) improve the pool2 implementation until we get somewhere close to
> >> jdbc-pool
> >>
> >> a) is non-trival and is really the focus of this e-mail.
> >>
> >> Issue 1
> >> =======
> >> DBCP isn't going to be able to use pool2 without some major
> re-factoring.
> >>
> >> My solution is:
> >> - copy current dbcp trunk to a branch
> >> - rename o.a.commons.dbcp to o.a.commons.dbcp2
> >> - update dependencies from pool to pool2
> >> - get it working
> >>
> >> Issue 2
> >> =======
> >> DBCP also ships with the o.a.commons.jocl package.
> >>
> >> There have been no jocl related questions on the users list since 2007.
> >> To prevent clashes between dbcp1 and dbcp2 I propose to simply drop JOCL
> >> support in dbcp2.
> >>
> >> Issue 3
> >> =======
> >> Minimum Java version.
> >>
> >> Supporting multiple JDBC API versions is a nuisance. I propose switching
> >> to a jdbc-pool style proxy approach. I also propose a minimum Java
> >> version of 5 to align with pool2.
> >>
> >> Issue 4
> >> =======
> >> Will the new dbcp work with Servlet containers?
> >>
> >> There were some concerns in this area with the pool2 re-factoring. This
> >> needs to be tested but my turn out to be a non-issue.
> >>
> >>
> >> I think these 4 issues need to be resolved before there is a pool2 or
> >> dbcp2 release.
> >>
> >>
> >> Assuming there are no objections, I plan to start committing along these
> >> lines in the next couple of days.
> >>
> >> Mark
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> >> For additional commands, e-mail: dev-help@commons.apache.org
> >>
> >>
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
--
Thank you,
Gary
http://garygregory.wordpress.com/
http://garygregory.com/
http://people.apache.org/~ggregory/
http://twitter.com/GaryGregory
Re: [DBCP] The plan for v2
Posted by Gary Gregory <ga...@gmail.com>.
On Tue, Mar 22, 2011 at 2:52 PM, Phil Steitz <ph...@gmail.com> wrote:
> On 3/22/11 11:20 AM, Mark Thomas wrote:
> > On 22/03/2011 17:58, Gary Gregory wrote:
> >> Hi Mark and all:
> >>
> >> It's good to hear someone is thinking about moving forward!
> >>
> >> pool2 trunk seems to me to be highly volatile based on having worked
> some in
> >> pool2.
> >>
> >> I've read opinions here going back and forth as to how to solidify the
> API
> >> or even go /back/ to the pool1 style before moving forward again.
> >>
> >> I think time would be better spent solidifying pool2. Time spent
> matching
> >> dbcp2 to pool2 could be a waste because, to me, pool2 feels like a
> moving
> >> target ATM.
> > pool2 is a moving target because a lot of the re-factoring has been an
> > academic exercise. Having a clear end user for this (Tomcat -> DBCP ->
> > POOL) should provide the direction necessary to solidify pool2. I don't
> > mind working with a moving target as long as it is moving towards a
> > clear goal. That goal for me is:
> > - Java 5 / generics
> > - fixing inconsistencies / oddities
> > - improved performance on DBCP in multi-core servers.
> +1
>
> Does the first item include replacing the wait/notify stuff with
> j.util.concurrent primitives?
> > It would certainly make starting dbcp2 a whole lot easier if most of the
> > pool2 re-factoring had not taken place. I think we made a mistake in not
> > pushing forward with DBCP and POOL in parallel. That said, I like a lot
> > of the pool2 changes and don't want to throw them away.
> >
> > What do folks think to the following:
> > - move pool trunk to a POOL_FUTURE branch
> > - restore pool trunk to a copy of the POOL_1_X branch
> > - rename pool package to o.a.c.pool2
> > (in reality this would probably be a merge from POOL_FUTURE)
> > - rename dbcp packages to o.a.c.dbcp2
> > - get pool2 and dbcp2 working together
> > - get Tomcat trunk working with dbcp2
> > - go through the POOL_FUTURE changes one at a time:
> > - merging it into pool2 trunk
> > - updating dbcp2 trunk if necessary
> > - testing updated dbcp2 with Tomcat
> > - if a POOL_FUTURE change breaks DBCP/Tomcat integration in a way that
> > can't easily be fixed skip that change and leave it in POOL_FUTURE
> I am fine with above, though I don't think there are any
> incompatible changes yet in the POOL_1_X branch or dbcp trunk, so
> steps 5 and 6 above are no-ops. I also don't want to be a stick in
> the mud, but it would be great to close the handful of issues open
> against POOL_1_X and cut a 1.5.5 before the copy so we could avoid
> having to port fixes. I will cut the release if we can agree on the
> fixes. Same holds for DBCP. A little concerted effort could get
> 1.3.1/1.4.1 out before cutting the new branch. I am fine, though,
> working these in parallel if that is what we want to do.
>
Detail: The next pool maintenance release will be 1.5.6; 1.5.5 is out.
Release early, release often, a la XP :)
Gary
>
> Phil
> > Mark
> >
> >> Min Java 5: +1!
> >>
> >> Gary
> >>
> >> On Tue, Mar 22, 2011 at 1:46 PM, Mark Thomas <ma...@apache.org> wrote:
> >>
> >>> Don't let the title get your hopes up. I don't have one yet, at least
> >>> not a complete one.
> >>> One of the primary driver for pool2 was to make use of
> >>> java.util.concurrent for the pool implementation and significantly
> >>> improve DBCP performance on multi-core systems (re-using ideas where we
> >>> can from Tomcat's jdbc-pool). I'm at the point where I have some time
> to
> >>> work on this.
> >>>
> >>> My very outline plan was as follows:
> >>> a) get DBCP working with pool2
> >>> b) run the jdbc-pool performance tests to see how much ground we need
> to
> >>> catch up
> >>> c) improve the pool2 implementation until we get somewhere close to
> >>> jdbc-pool
> >>>
> >>> a) is non-trival and is really the focus of this e-mail.
> >>>
> >>> Issue 1
> >>> =======
> >>> DBCP isn't going to be able to use pool2 without some major
> re-factoring.
> >>>
> >>> My solution is:
> >>> - copy current dbcp trunk to a branch
> >>> - rename o.a.commons.dbcp to o.a.commons.dbcp2
> >>> - update dependencies from pool to pool2
> >>> - get it working
> >>>
> >>> Issue 2
> >>> =======
> >>> DBCP also ships with the o.a.commons.jocl package.
> >>>
> >>> There have been no jocl related questions on the users list since 2007.
> >>> To prevent clashes between dbcp1 and dbcp2 I propose to simply drop
> JOCL
> >>> support in dbcp2.
> >>>
> >>> Issue 3
> >>> =======
> >>> Minimum Java version.
> >>>
> >>> Supporting multiple JDBC API versions is a nuisance. I propose
> switching
> >>> to a jdbc-pool style proxy approach. I also propose a minimum Java
> >>> version of 5 to align with pool2.
> >>>
> >>> Issue 4
> >>> =======
> >>> Will the new dbcp work with Servlet containers?
> >>>
> >>> There were some concerns in this area with the pool2 re-factoring. This
> >>> needs to be tested but my turn out to be a non-issue.
> >>>
> >>>
> >>> I think these 4 issues need to be resolved before there is a pool2 or
> >>> dbcp2 release.
> >>>
> >>>
> >>> Assuming there are no objections, I plan to start committing along
> these
> >>> lines in the next couple of days.
> >>>
> >>> Mark
> >>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> >>> For additional commands, e-mail: dev-help@commons.apache.org
> >>>
> >>>
> >>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > For additional commands, e-mail: dev-help@commons.apache.org
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
--
Thank you,
Gary
http://garygregory.wordpress.com/
http://garygregory.com/
http://people.apache.org/~ggregory/
http://twitter.com/GaryGregory
Re: [DBCP] The plan for v2
Posted by Mark Thomas <ma...@apache.org>.
On 23/03/2011 11:00, Simone Tripodi wrote:
> Thanks a lot Mark, much more than appreciated :)
> I'm +1 to support your idea of moving the current pool2 code in a
> branch, then continue the 1.5.5 work. The useful part that IMHO can be
> backported are the use of generics, replacing primitive constants with
> enumerations, removing some useless wrappers in the PoolUtils class
> such the checked pool (we agreed pools are checked due the generics
> adoption) and the synchronized pools (they can be implemented via
> Proxies).
> The rest of the design "improvement" can be ignored, I'm not convinced
> at all that current code contains the APIs I would like to use as a
> user.
>
> I don't have an idea yet on how to introduce java.util.concurrent, I
> guess there are betters contributors in this area.
>
> BTW count on me, I should be able to replicate the code modifications
> in a short while (1 night should be enough :P)
Brilliant. I'll fix the remaining 1.5.x issues first so we are in a
position to do a 1.5.6 release and then I'll look at doing the
re-organising.
The DBCP backlog looks rather larger so I may create dbcp2 before all of
them get fixed. I'll see how things go.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [DBCP] The plan for v2
Posted by Simone Tripodi <si...@apache.org>.
Thanks a lot Mark, much more than appreciated :)
I'm +1 to support your idea of moving the current pool2 code in a
branch, then continue the 1.5.5 work. The useful part that IMHO can be
backported are the use of generics, replacing primitive constants with
enumerations, removing some useless wrappers in the PoolUtils class
such the checked pool (we agreed pools are checked due the generics
adoption) and the synchronized pools (they can be implemented via
Proxies).
The rest of the design "improvement" can be ignored, I'm not convinced
at all that current code contains the APIs I would like to use as a
user.
I don't have an idea yet on how to introduce java.util.concurrent, I
guess there are betters contributors in this area.
BTW count on me, I should be able to replicate the code modifications
in a short while (1 night should be enough :P)
Have a nice day, all the best,
Simo
http://people.apache.org/~simonetripodi/
http://www.99soft.org/
On Wed, Mar 23, 2011 at 10:41 AM, Mark Thomas <ma...@apache.org> wrote:
> On 23/03/2011 08:33, Simone Tripodi wrote:
>> Hi all,
>> sorry to join late the conversation but looks like living in a
>> different timezone *is* an issue :(
>
> No need to apologise. I wasn't going to go ahead until you had a chance
> to give your feedback.
>
>> I am the person "physically" responsable of the pool2 "big
>> refactoring" and I would be very sorry to see all that work dropped or
>> be useless; if you follow the old pool2 discussion in this ML that
>> drove the refactoring, you would maybe agree that I'm not just a crazy
>> guy :)
>
> I did follow it and I broadly agreed with each of the steps. What I
> hadn't truly appreciated was how much things had changed and the work
> that would be required to get a dbcp2 working with it.
>
>> BTW I agree with Gary vision, things would have worked simpler just
>> adding the generics in pool-1.X and releasing as 2.0, then applying
>> changes/merging fixes step by step, releasing "early and often"
>> following the XP best practice.
>
> I think there is general agreement here that small steps are good.
>
>> Can I still be helpful here? I would be much more than happy to use
>> the pool2 with generics ASAP, so it's part of my interest too :)
>
> Absolutely! If we do go down the POOL_FUTURE + backport route I'm sure
> there will be plenty of discussion about some of the backports as well
> as the work on dbcp2. Any and all help would be appreciated.
>
> If you have any thoughts on the best way to get from where we are to a
> dbcp2 that uses pool2 where the core pooling code has been updated to
> take advantage of java.util.concurrent then please do share them.
>
> Mark
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [DBCP] The plan for v2
Posted by Mark Thomas <ma...@apache.org>.
On 23/03/2011 08:33, Simone Tripodi wrote:
> Hi all,
> sorry to join late the conversation but looks like living in a
> different timezone *is* an issue :(
No need to apologise. I wasn't going to go ahead until you had a chance
to give your feedback.
> I am the person "physically" responsable of the pool2 "big
> refactoring" and I would be very sorry to see all that work dropped or
> be useless; if you follow the old pool2 discussion in this ML that
> drove the refactoring, you would maybe agree that I'm not just a crazy
> guy :)
I did follow it and I broadly agreed with each of the steps. What I
hadn't truly appreciated was how much things had changed and the work
that would be required to get a dbcp2 working with it.
> BTW I agree with Gary vision, things would have worked simpler just
> adding the generics in pool-1.X and releasing as 2.0, then applying
> changes/merging fixes step by step, releasing "early and often"
> following the XP best practice.
I think there is general agreement here that small steps are good.
> Can I still be helpful here? I would be much more than happy to use
> the pool2 with generics ASAP, so it's part of my interest too :)
Absolutely! If we do go down the POOL_FUTURE + backport route I'm sure
there will be plenty of discussion about some of the backports as well
as the work on dbcp2. Any and all help would be appreciated.
If you have any thoughts on the best way to get from where we are to a
dbcp2 that uses pool2 where the core pooling code has been updated to
take advantage of java.util.concurrent then please do share them.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [DBCP] The plan for v2
Posted by Simone Tripodi <si...@apache.org>.
Hi all,
sorry to join late the conversation but looks like living in a
different timezone *is* an issue :(
I am the person "physically" responsable of the pool2 "big
refactoring" and I would be very sorry to see all that work dropped or
be useless; if you follow the old pool2 discussion in this ML that
drove the refactoring, you would maybe agree that I'm not just a crazy
guy :)
BTW I agree with Gary vision, things would have worked simpler just
adding the generics in pool-1.X and releasing as 2.0, then applying
changes/merging fixes step by step, releasing "early and often"
following the XP best practice.
Can I still be helpful here? I would be much more than happy to use
the pool2 with generics ASAP, so it's part of my interest too :)
Have a nice day, all the best,
Simo
http://people.apache.org/~simonetripodi/
http://www.99soft.org/
On Tue, Mar 22, 2011 at 8:24 PM, Mark Thomas <ma...@apache.org> wrote:
> On 22/03/2011 18:52, Phil Steitz wrote:
>> On 3/22/11 11:20 AM, Mark Thomas wrote:
> <snip/>
>> I don't
>>> mind working with a moving target as long as it is moving towards a
>>> clear goal. That goal for me is:
>>> - Java 5 / generics
>>> - fixing inconsistencies / oddities
>>> - improved performance on DBCP in multi-core servers.
>> +1
>>
>> Does the first item include replacing the wait/notify stuff with
>> j.util.concurrent primitives?
>
> Yes, in combination with the third item.
>
>>> It would certainly make starting dbcp2 a whole lot easier if most of the
>>> pool2 re-factoring had not taken place. I think we made a mistake in not
>>> pushing forward with DBCP and POOL in parallel. That said, I like a lot
>>> of the pool2 changes and don't want to throw them away.
>>>
>>> What do folks think to the following:
>>> - move pool trunk to a POOL_FUTURE branch
>>> - restore pool trunk to a copy of the POOL_1_X branch
>>> - rename pool package to o.a.c.pool2
>>> (in reality this would probably be a merge from POOL_FUTURE)
>>> - rename dbcp packages to o.a.c.dbcp2
>>> - get pool2 and dbcp2 working together
>>> - get Tomcat trunk working with dbcp2
>>> - go through the POOL_FUTURE changes one at a time:
>>> - merging it into pool2 trunk
>>> - updating dbcp2 trunk if necessary
>>> - testing updated dbcp2 with Tomcat
>>> - if a POOL_FUTURE change breaks DBCP/Tomcat integration in a way that
>>> can't easily be fixed skip that change and leave it in POOL_FUTURE
>> I am fine with above, though I don't think there are any
>> incompatible changes yet in the POOL_1_X branch or dbcp trunk, so
>> steps 5 and 6 above are no-ops.
>
> Not quite no-ops. There will be some imports to rename but that should
> be the limit of it.
>
>> I also don't want to be a stick in
>> the mud, but it would be great to close the handful of issues open
>> against POOL_1_X and cut a 1.5.5 before the copy so we could avoid
>> having to port fixes. I will cut the release if we can agree on the
>> fixes. Same holds for DBCP. A little concerted effort could get
>> 1.3.1/1.4.1 out before cutting the new branch.
>
> That makes sense to me. It also gives folks a chance to chime in with
> their views on the plan.
>
> Mark
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [DBCP] The plan for v2
Posted by Mark Thomas <ma...@apache.org>.
On 22/03/2011 18:52, Phil Steitz wrote:
> On 3/22/11 11:20 AM, Mark Thomas wrote:
<snip/>
> I don't
>> mind working with a moving target as long as it is moving towards a
>> clear goal. That goal for me is:
>> - Java 5 / generics
>> - fixing inconsistencies / oddities
>> - improved performance on DBCP in multi-core servers.
> +1
>
> Does the first item include replacing the wait/notify stuff with
> j.util.concurrent primitives?
Yes, in combination with the third item.
>> It would certainly make starting dbcp2 a whole lot easier if most of the
>> pool2 re-factoring had not taken place. I think we made a mistake in not
>> pushing forward with DBCP and POOL in parallel. That said, I like a lot
>> of the pool2 changes and don't want to throw them away.
>>
>> What do folks think to the following:
>> - move pool trunk to a POOL_FUTURE branch
>> - restore pool trunk to a copy of the POOL_1_X branch
>> - rename pool package to o.a.c.pool2
>> (in reality this would probably be a merge from POOL_FUTURE)
>> - rename dbcp packages to o.a.c.dbcp2
>> - get pool2 and dbcp2 working together
>> - get Tomcat trunk working with dbcp2
>> - go through the POOL_FUTURE changes one at a time:
>> - merging it into pool2 trunk
>> - updating dbcp2 trunk if necessary
>> - testing updated dbcp2 with Tomcat
>> - if a POOL_FUTURE change breaks DBCP/Tomcat integration in a way that
>> can't easily be fixed skip that change and leave it in POOL_FUTURE
> I am fine with above, though I don't think there are any
> incompatible changes yet in the POOL_1_X branch or dbcp trunk, so
> steps 5 and 6 above are no-ops.
Not quite no-ops. There will be some imports to rename but that should
be the limit of it.
> I also don't want to be a stick in
> the mud, but it would be great to close the handful of issues open
> against POOL_1_X and cut a 1.5.5 before the copy so we could avoid
> having to port fixes. I will cut the release if we can agree on the
> fixes. Same holds for DBCP. A little concerted effort could get
> 1.3.1/1.4.1 out before cutting the new branch.
That makes sense to me. It also gives folks a chance to chime in with
their views on the plan.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [DBCP] The plan for v2
Posted by Phil Steitz <ph...@gmail.com>.
On 3/22/11 11:20 AM, Mark Thomas wrote:
> On 22/03/2011 17:58, Gary Gregory wrote:
>> Hi Mark and all:
>>
>> It's good to hear someone is thinking about moving forward!
>>
>> pool2 trunk seems to me to be highly volatile based on having worked some in
>> pool2.
>>
>> I've read opinions here going back and forth as to how to solidify the API
>> or even go /back/ to the pool1 style before moving forward again.
>>
>> I think time would be better spent solidifying pool2. Time spent matching
>> dbcp2 to pool2 could be a waste because, to me, pool2 feels like a moving
>> target ATM.
> pool2 is a moving target because a lot of the re-factoring has been an
> academic exercise. Having a clear end user for this (Tomcat -> DBCP ->
> POOL) should provide the direction necessary to solidify pool2. I don't
> mind working with a moving target as long as it is moving towards a
> clear goal. That goal for me is:
> - Java 5 / generics
> - fixing inconsistencies / oddities
> - improved performance on DBCP in multi-core servers.
+1
Does the first item include replacing the wait/notify stuff with
j.util.concurrent primitives?
> It would certainly make starting dbcp2 a whole lot easier if most of the
> pool2 re-factoring had not taken place. I think we made a mistake in not
> pushing forward with DBCP and POOL in parallel. That said, I like a lot
> of the pool2 changes and don't want to throw them away.
>
> What do folks think to the following:
> - move pool trunk to a POOL_FUTURE branch
> - restore pool trunk to a copy of the POOL_1_X branch
> - rename pool package to o.a.c.pool2
> (in reality this would probably be a merge from POOL_FUTURE)
> - rename dbcp packages to o.a.c.dbcp2
> - get pool2 and dbcp2 working together
> - get Tomcat trunk working with dbcp2
> - go through the POOL_FUTURE changes one at a time:
> - merging it into pool2 trunk
> - updating dbcp2 trunk if necessary
> - testing updated dbcp2 with Tomcat
> - if a POOL_FUTURE change breaks DBCP/Tomcat integration in a way that
> can't easily be fixed skip that change and leave it in POOL_FUTURE
I am fine with above, though I don't think there are any
incompatible changes yet in the POOL_1_X branch or dbcp trunk, so
steps 5 and 6 above are no-ops. I also don't want to be a stick in
the mud, but it would be great to close the handful of issues open
against POOL_1_X and cut a 1.5.5 before the copy so we could avoid
having to port fixes. I will cut the release if we can agree on the
fixes. Same holds for DBCP. A little concerted effort could get
1.3.1/1.4.1 out before cutting the new branch. I am fine, though,
working these in parallel if that is what we want to do.
Phil
> Mark
>
>> Min Java 5: +1!
>>
>> Gary
>>
>> On Tue, Mar 22, 2011 at 1:46 PM, Mark Thomas <ma...@apache.org> wrote:
>>
>>> Don't let the title get your hopes up. I don't have one yet, at least
>>> not a complete one.
>>> One of the primary driver for pool2 was to make use of
>>> java.util.concurrent for the pool implementation and significantly
>>> improve DBCP performance on multi-core systems (re-using ideas where we
>>> can from Tomcat's jdbc-pool). I'm at the point where I have some time to
>>> work on this.
>>>
>>> My very outline plan was as follows:
>>> a) get DBCP working with pool2
>>> b) run the jdbc-pool performance tests to see how much ground we need to
>>> catch up
>>> c) improve the pool2 implementation until we get somewhere close to
>>> jdbc-pool
>>>
>>> a) is non-trival and is really the focus of this e-mail.
>>>
>>> Issue 1
>>> =======
>>> DBCP isn't going to be able to use pool2 without some major re-factoring.
>>>
>>> My solution is:
>>> - copy current dbcp trunk to a branch
>>> - rename o.a.commons.dbcp to o.a.commons.dbcp2
>>> - update dependencies from pool to pool2
>>> - get it working
>>>
>>> Issue 2
>>> =======
>>> DBCP also ships with the o.a.commons.jocl package.
>>>
>>> There have been no jocl related questions on the users list since 2007.
>>> To prevent clashes between dbcp1 and dbcp2 I propose to simply drop JOCL
>>> support in dbcp2.
>>>
>>> Issue 3
>>> =======
>>> Minimum Java version.
>>>
>>> Supporting multiple JDBC API versions is a nuisance. I propose switching
>>> to a jdbc-pool style proxy approach. I also propose a minimum Java
>>> version of 5 to align with pool2.
>>>
>>> Issue 4
>>> =======
>>> Will the new dbcp work with Servlet containers?
>>>
>>> There were some concerns in this area with the pool2 re-factoring. This
>>> needs to be tested but my turn out to be a non-issue.
>>>
>>>
>>> I think these 4 issues need to be resolved before there is a pool2 or
>>> dbcp2 release.
>>>
>>>
>>> Assuming there are no objections, I plan to start committing along these
>>> lines in the next couple of days.
>>>
>>> Mark
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [DBCP] The plan for v2
Posted by Mark Thomas <ma...@apache.org>.
On 22/03/2011 17:58, Gary Gregory wrote:
> Hi Mark and all:
>
> It's good to hear someone is thinking about moving forward!
>
> pool2 trunk seems to me to be highly volatile based on having worked some in
> pool2.
>
> I've read opinions here going back and forth as to how to solidify the API
> or even go /back/ to the pool1 style before moving forward again.
>
> I think time would be better spent solidifying pool2. Time spent matching
> dbcp2 to pool2 could be a waste because, to me, pool2 feels like a moving
> target ATM.
pool2 is a moving target because a lot of the re-factoring has been an
academic exercise. Having a clear end user for this (Tomcat -> DBCP ->
POOL) should provide the direction necessary to solidify pool2. I don't
mind working with a moving target as long as it is moving towards a
clear goal. That goal for me is:
- Java 5 / generics
- fixing inconsistencies / oddities
- improved performance on DBCP in multi-core servers.
It would certainly make starting dbcp2 a whole lot easier if most of the
pool2 re-factoring had not taken place. I think we made a mistake in not
pushing forward with DBCP and POOL in parallel. That said, I like a lot
of the pool2 changes and don't want to throw them away.
What do folks think to the following:
- move pool trunk to a POOL_FUTURE branch
- restore pool trunk to a copy of the POOL_1_X branch
- rename pool package to o.a.c.pool2
(in reality this would probably be a merge from POOL_FUTURE)
- rename dbcp packages to o.a.c.dbcp2
- get pool2 and dbcp2 working together
- get Tomcat trunk working with dbcp2
- go through the POOL_FUTURE changes one at a time:
- merging it into pool2 trunk
- updating dbcp2 trunk if necessary
- testing updated dbcp2 with Tomcat
- if a POOL_FUTURE change breaks DBCP/Tomcat integration in a way that
can't easily be fixed skip that change and leave it in POOL_FUTURE
Mark
> Min Java 5: +1!
>
> Gary
>
> On Tue, Mar 22, 2011 at 1:46 PM, Mark Thomas <ma...@apache.org> wrote:
>
>> Don't let the title get your hopes up. I don't have one yet, at least
>> not a complete one.
>> One of the primary driver for pool2 was to make use of
>> java.util.concurrent for the pool implementation and significantly
>> improve DBCP performance on multi-core systems (re-using ideas where we
>> can from Tomcat's jdbc-pool). I'm at the point where I have some time to
>> work on this.
>>
>> My very outline plan was as follows:
>> a) get DBCP working with pool2
>> b) run the jdbc-pool performance tests to see how much ground we need to
>> catch up
>> c) improve the pool2 implementation until we get somewhere close to
>> jdbc-pool
>>
>> a) is non-trival and is really the focus of this e-mail.
>>
>> Issue 1
>> =======
>> DBCP isn't going to be able to use pool2 without some major re-factoring.
>>
>> My solution is:
>> - copy current dbcp trunk to a branch
>> - rename o.a.commons.dbcp to o.a.commons.dbcp2
>> - update dependencies from pool to pool2
>> - get it working
>>
>> Issue 2
>> =======
>> DBCP also ships with the o.a.commons.jocl package.
>>
>> There have been no jocl related questions on the users list since 2007.
>> To prevent clashes between dbcp1 and dbcp2 I propose to simply drop JOCL
>> support in dbcp2.
>>
>> Issue 3
>> =======
>> Minimum Java version.
>>
>> Supporting multiple JDBC API versions is a nuisance. I propose switching
>> to a jdbc-pool style proxy approach. I also propose a minimum Java
>> version of 5 to align with pool2.
>>
>> Issue 4
>> =======
>> Will the new dbcp work with Servlet containers?
>>
>> There were some concerns in this area with the pool2 re-factoring. This
>> needs to be tested but my turn out to be a non-issue.
>>
>>
>> I think these 4 issues need to be resolved before there is a pool2 or
>> dbcp2 release.
>>
>>
>> Assuming there are no objections, I plan to start committing along these
>> lines in the next couple of days.
>>
>> Mark
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [DBCP] The plan for v2
Posted by Gary Gregory <ga...@gmail.com>.
Hi Mark and all:
It's good to hear someone is thinking about moving forward!
pool2 trunk seems to me to be highly volatile based on having worked some in
pool2.
I've read opinions here going back and forth as to how to solidify the API
or even go /back/ to the pool1 style before moving forward again.
I think time would be better spent solidifying pool2. Time spent matching
dbcp2 to pool2 could be a waste because, to me, pool2 feels like a moving
target ATM.
Min Java 5: +1!
Gary
On Tue, Mar 22, 2011 at 1:46 PM, Mark Thomas <ma...@apache.org> wrote:
> Don't let the title get your hopes up. I don't have one yet, at least
> not a complete one.
> One of the primary driver for pool2 was to make use of
> java.util.concurrent for the pool implementation and significantly
> improve DBCP performance on multi-core systems (re-using ideas where we
> can from Tomcat's jdbc-pool). I'm at the point where I have some time to
> work on this.
>
> My very outline plan was as follows:
> a) get DBCP working with pool2
> b) run the jdbc-pool performance tests to see how much ground we need to
> catch up
> c) improve the pool2 implementation until we get somewhere close to
> jdbc-pool
>
> a) is non-trival and is really the focus of this e-mail.
>
> Issue 1
> =======
> DBCP isn't going to be able to use pool2 without some major re-factoring.
>
> My solution is:
> - copy current dbcp trunk to a branch
> - rename o.a.commons.dbcp to o.a.commons.dbcp2
> - update dependencies from pool to pool2
> - get it working
>
> Issue 2
> =======
> DBCP also ships with the o.a.commons.jocl package.
>
> There have been no jocl related questions on the users list since 2007.
> To prevent clashes between dbcp1 and dbcp2 I propose to simply drop JOCL
> support in dbcp2.
>
> Issue 3
> =======
> Minimum Java version.
>
> Supporting multiple JDBC API versions is a nuisance. I propose switching
> to a jdbc-pool style proxy approach. I also propose a minimum Java
> version of 5 to align with pool2.
>
> Issue 4
> =======
> Will the new dbcp work with Servlet containers?
>
> There were some concerns in this area with the pool2 re-factoring. This
> needs to be tested but my turn out to be a non-issue.
>
>
> I think these 4 issues need to be resolved before there is a pool2 or
> dbcp2 release.
>
>
> Assuming there are no objections, I plan to start committing along these
> lines in the next couple of days.
>
> Mark
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
--
Thank you,
Gary
http://garygregory.wordpress.com/
http://garygregory.com/
http://people.apache.org/~ggregory/
http://twitter.com/GaryGregory