Release 1.3 soon?

Are there any DBCP-1.3 release plans?  Based on the JIRAs I
think we  
are close to being ready to release.  Are there any items
that are  
planned but don't have JIRAs?

-dain

Here are some open JIRAs I think we can close:

Fixed:
DBCP-194 BasicDataSource.setLogWriter should not do
createDataSource
DBCP-102 setReadOnly & setAutoCommit called too many
times
DBCP-97 setAutoCommit(true) when returning connection to the
pool
DBCP-212 PoolingDataSource closes physical connections

Invalid:
DBCP-209 Is DataSource.getConnection(user, pass) working the
way it  
is suppose to?
User should be using either SharedPoolDataSource or the  
PerUserPoolDataSource.
DBCP-53 commons dbcp does not supports Firebird DB
Torque bug or misconfiguration by user.

Won't fix
DBCP-115 allow to set >= 6 parameters to do non-global
SSL
Request for mysql specific feature
DBCP-152 add a socketFactory attribute to BasicDataSource
(to allow  
SSL "thread"-safe)
Request for mysql specific feature


------------------------------------------------------------
---------
To unsubscribe, e-mail: commons-dev-unsubscribejakarta.apache.org
For additional commands, e-mail: commons-dev-helpjakarta.apache.org

On 7/19/07, Dain Sundstrom <dainiq80.com> wrote:
> Are there any DBCP-1.3 release plans?  Based on the
JIRAs I think we
> are close to being ready to release.  Are there any
items that are
> planned but don't have JIRAs?

There are two things that I would like to at least talk
about that
relate to various JIRAs and comments on the list:

1) Intended current and future contract of close() on a
connection
pool, in particular the contract of BasicDataSource.close. 
The
javadoc says "Close and release all connections that
are currently
stored in the connection pool associated with our data
source."  Some
users interpret this - incorrectly - to mean that close will
close
*active* as well as idle connections.  Even when
AbandonedConfig is
used (in which case the pool holds references to connections
that have
been checked out), close only closes idle connections (since
the
"pool" is really and idle object pool).  So the
answer to the question
in, e.g. DBCP-221, is "sorry, no way to do that." 
Javadoc should be
improved in any case.

2) Immutable-once-initialized status of BasicDataSource.  I
am
inclined to close  	 DBCP-221 as WONTFIX, but in this case
we should
rip out the remnants of what must have seemed like a good
idea at the
time to support "restart".  This is sort of
related to 1), because if
we are going to attempt to allow BasicDataSource to be
mutable once it
has been initialized, I don't see any way to do that
consistently
without closing or appropriately modifying connections that
have been
checked out.  Since we don't do that now, we can't really
support
this.  My vote would be to keep BasicDataSource
"immutable-once-initialized".
>
> Here are some open JIRAs I think we can close:
>
> Fixed:
> DBCP-194 BasicDataSource.setLogWriter should not do
createDataSource
> DBCP-102 setReadOnly & setAutoCommit called too
many times
> DBCP-97 setAutoCommit(true) when returning connection
to the pool
> DBCP-212 PoolingDataSource closes physical connections
>
+1 and thanks for verifying 97.

> Invalid:
> DBCP-209 Is DataSource.getConnection(user, pass)
working the way it
> is suppose to?
> User should be using either SharedPoolDataSource or
the
> PerUserPoolDataSource.
> DBCP-53 commons dbcp does not supports Firebird DB
> Torque bug or misconfiguration by user.
>
+1

> Won't fix
> DBCP-115 allow to set >= 6 parameters to do
non-global SSL
> Request for mysql specific feature
> DBCP-152 add a socketFactory attribute to
BasicDataSource (to allow
> SSL "thread"-safe)
> Request for mysql specific feature
>
+1

I would love to have a fix for DBCP-44; but that could wait
on pool
1.4 if necessary (and Ipersonally see no way to fix it just
within
dbcp.  It would be great if I was wrong on that).

We should also address DBCP-4  (by using jdk logging, since
we have
bumped to 1.4 level).  I think it would be good to start
adding some
simple instrumentation in 1.3 that we could add to in
subsequent
releases.  Having things like physical connection opens /
closes, pool
high water marks, waits, etc., loggable would make debuggng
and
performance tuning much easier.

I will finish reviewing recent patches tomorrow and come up
with a
straw man release plan this weekend if no one beats me to
it.

Thanks for all of your help on this, Dain.

Phil

------------------------------------------------------------
---------
To unsubscribe, e-mail: commons-dev-unsubscribejakarta.apache.org
For additional commands, e-mail: commons-dev-helpjakarta.apache.org

On Jul 19, 2007, at 11:19 PM, Phil Steitz wrote:

>> Here are some open JIRAs I think we can close:
>>
>> Fixed:
>> DBCP-194 BasicDataSource.setLogWriter should not do
createDataSource
>> DBCP-102 setReadOnly & setAutoCommit called too
many times
>> DBCP-97 setAutoCommit(true) when returning
connection to the pool
>> DBCP-212 PoolingDataSource closes physical
connections
>>
> +1 and thanks for verifying 97.
>
>> Invalid:
>> DBCP-209 Is DataSource.getConnection(user, pass)
working the way it
>> is suppose to?
>> User should be using either SharedPoolDataSource or
the
>> PerUserPoolDataSource.
>> DBCP-53 commons dbcp does not supports Firebird DB
>> Torque bug or misconfiguration by user.
>>
> +1
>
>> Won't fix
>> DBCP-115 allow to set >= 6 parameters to do
non-global SSL
>> Request for mysql specific feature
>> DBCP-152 add a socketFactory attribute to
BasicDataSource (to allow
>> SSL "thread"-safe)
>> Request for mysql specific feature
>>
> +1

If you grant me DBCP JIRA karma, I can make these changes
myself.   
I'm a JIRA admin, so you just need to grant me karma here
(email) and  
I can add the permission to JIRA myself.

-dain

------------------------------------------------------------
---------
To unsubscribe, e-mail: commons-dev-unsubscribejakarta.apache.org
For additional commands, e-mail: commons-dev-helpjakarta.apache.org

On Jul 19, 2007, at 11:19 PM, Phil Steitz wrote:

> On 7/19/07, Dain Sundstrom <dainiq80.com> wrote:
>> Are there any DBCP-1.3 release plans?  Based on the
JIRAs I think we
>> are close to being ready to release.  Are there any
items that are
>> planned but don't have JIRAs?
>
> There are two things that I would like to at least talk
about that
> relate to various JIRAs and comments on the list:
>
> 1) Intended current and future contract of close() on a
connection
> pool, in particular the contract of
BasicDataSource.close.  The
> javadoc says "Close and release all connections
that are currently
> stored in the connection pool associated with our data
source."  Some
> users interpret this - incorrectly - to mean that close
will close
> *active* as well as idle connections.  Even when
AbandonedConfig is
> used (in which case the pool holds references to
connections that have
> been checked out), close only closes idle connections
(since the
> "pool" is really and idle object pool).  So
the answer to the question
> in, e.g. DBCP-221, is "sorry, no way to do
that."  Javadoc should be
> improved in any case.
>
> 2) Immutable-once-initialized status of
BasicDataSource.  I am
> inclined to close  	 DBCP-221 as WONTFIX, but in this
case we should
> rip out the remnants of what must have seemed like a
good idea at the
> time to support "restart".  This is sort of
related to 1), because if
> we are going to attempt to allow BasicDataSource to be
mutable once it
> has been initialized, I don't see any way to do that
consistently
> without closing or appropriately modifying connections
that have been
> checked out.  Since we don't do that now, we can't
really support
> this.  My vote would be to keep BasicDataSource
> "immutable-once-initialized".

I think these are basically the same issue.  I agree with
the  
comments in DBCP-221 which seems to want a lingering close. 
This is  
in line with how I expect close to work (having not read any
of the  
pooling code yet).

I think the root of this problem is we don't have a clear
start/stop  
life-cycle methods.  Currently, we are using the first
getConnection 
() for start and close() for stop, which I think are good
choices.   
Maybe we could keep those choices, and introduce an explicit
start(),  
stop() and stop(long maxWait).  This way we can support the
close  
lingering and close immediately options people seem to be
asking  
for.  Once we have this functionality, it should be easy to
add  
restart() which would close() lingering the existing inner
datasource  
and create/start a new one.

I'm not sure this is something that can be done without
changes to  
pool, but I'll take a look at it today.

<snip/>

> I would love to have a fix for DBCP-44; but that could
wait on pool
> 1.4 if necessary (and Ipersonally see no way to fix it
just within
> dbcp.  It would be great if I was wrong on that).

I think the makeObject method is over synchronized. 
Actually, the  
class doesn't look it's synchronized properly at all.  I'll
take a  
shot at fixing this.

> We should also address DBCP-4  (by using jdk logging,
since we have
> bumped to 1.4 level).  I think it would be good to
start adding some
> simple instrumentation in 1.3 that we could add to in
subsequent
> releases.  Having things like physical connection opens
/ closes, pool
> high water marks, waits, etc., loggable would make
debuggng and
> performance tuning much easier.

In the future, I'd like these events to be available via a
listener  
interface, so I can write monitoring code (like an mbean). 
Of course  
working out that interface takes time, so I think we should
add the  
logging in 1.3 and a listener in 1.4.

Are there any notes on how we'd like to use util.Logging
(log names,  
levels, etc.)?

> I will finish reviewing recent patches tomorrow and
come up with a
> straw man release plan this weekend if no one beats me
to it.

I'll look at DBCP-44 since I think it is an easy small fix. 
Then the  
close() issue and finally logging, unless someone beats me
to them.

BTW, it is getting challenging to write new patches with the
current  
patches I have out.  I have been trying to keep patches so
there  
aren't file overlaps.  I may need to start putting ordering 

information into the patches like apply after DBCP-1234.

> Thanks for all of your help on this, Dain.

No prob.  This code is like programming crack for me....
Small tasks  
for a big programming high 

-dain

------------------------------------------------------------
---------
To unsubscribe, e-mail: commons-dev-unsubscribejakarta.apache.org
For additional commands, e-mail: commons-dev-helpjakarta.apache.org

On Jul 20, 2007, at 11:26 AM, Dain Sundstrom wrote:

> On Jul 19, 2007, at 11:19 PM, Phil Steitz wrote:
>
>> I would love to have a fix for DBCP-44; but that
could wait on pool
>> 1.4 if necessary (and Ipersonally see no way to fix
it just within
>> dbcp.  It would be great if I was wrong on that).
>
> I think the makeObject method is over synchronized. 
Actually, the  
> class doesn't look it's synchronized properly at all. 
I'll take a  
> shot at fixing this.

I attached a patch that fixes the synchronization in  
PoolableConnectionFactory, but the deadlock still persists. 
The  
problem is GenericObjectPool.borrowObject() is synchronized
so when  
it needs to makeObject that method is called while the
synchronized  
block is held.  I think this would take major surgery to
make  
GenericObjectPool not perform this way.

I think the way to solve this is to write a new pool
implementation  
that is much more async.  This easier with the Java5
concurrent  
packages, but still quite tricky.  I'll attempt to put
together one  
in a few days.  Regardless, I don't think this is something
we should  
target for this release.

-dain

------------------------------------------------------------
---------
To unsubscribe, e-mail: commons-dev-unsubscribejakarta.apache.org
For additional commands, e-mail: commons-dev-helpjakarta.apache.org

On 7/20/07, Dain Sundstrom <dainiq80.com> wrote:
> On Jul 20, 2007, at 11:26 AM, Dain Sundstrom wrote:
>
> > On Jul 19, 2007, at 11:19 PM, Phil Steitz wrote:
> >
> >> I would love to have a fix for DBCP-44; but
that could wait on pool
> >> 1.4 if necessary (and Ipersonally see no way
to fix it just within
> >> dbcp.  It would be great if I was wrong on
that).
> >
> > I think the makeObject method is over
synchronized.  Actually, the
> > class doesn't look it's synchronized properly at
all.  I'll take a
> > shot at fixing this.
>
> I attached a patch that fixes the synchronization in
> PoolableConnectionFactory, but the deadlock still
persists.  The
> problem is GenericObjectPool.borrowObject() is
synchronized so when
> it needs to makeObject that method is called while the
synchronized
> block is held.  I think this would take major surgery
to make
> GenericObjectPool not perform this way.

Thats what I feared.  Thanks for looking in any case.
>
> I think the way to solve this is to write a new pool
implementation
> that is much more async.  This easier with the Java5
concurrent
> packages, but still quite tricky.

Yes, and at least for dbcp 1.3, I would prefer not to hop
all the way
to 1.5 required JDK level.

 I'll attempt to put together one
> in a few days.  Regardless, I don't think this is
something we should
> target for this release.

Before writing another one, have a look at the compositepool
package
in pool head.

>
> -dain
>
>
------------------------------------------------------------
---------
> To unsubscribe, e-mail: commons-dev-unsubscribejakarta.apache.org
> For additional commands, e-mail: commons-dev-helpjakarta.apache.org
>
>

------------------------------------------------------------
---------
To unsubscribe, e-mail: commons-dev-unsubscribejakarta.apache.org
For additional commands, e-mail: commons-dev-helpjakarta.apache.org

On Jul 20, 2007, at 5:26 PM, Phil Steitz wrote:

> On 7/20/07, Dain Sundstrom <dainiq80.com> wrote:
>>
>> On Jul 20, 2007, at 11:26 AM, Dain Sundstrom
wrote:
>>
>> > On Jul 19, 2007, at 11:19 PM, Phil Steitz
wrote:
>> >
>> >> I would love to have a fix for DBCP-44;
but that could wait on  
>> pool
>> >> 1.4 if necessary (and Ipersonally see no
way to fix it just within
>> >> dbcp.  It would be great if I was wrong on
that).
>> >
>> > I think the makeObject method is over
synchronized.  Actually, the
>> > class doesn't look it's synchronized properly
at all.  I'll take a
>> > shot at fixing this.
>>
>> I attached a patch that fixes the synchronization
in
>> PoolableConnectionFactory, but the deadlock still
persists.  The
>> problem is GenericObjectPool.borrowObject() is
synchronized so when
>> it needs to makeObject that method is called while
the synchronized
>> block is held.  I think this would take major
surgery to make
>> GenericObjectPool not perform this way.
>
> Thats what I feared.  Thanks for looking in any case.
>>
>> I think the way to solve this is to write a new
pool implementation
>> that is much more async.  This easier with the
Java5 concurrent
>> packages, but still quite tricky.
>
> Yes, and at least for dbcp 1.3, I would prefer not to
hop all the way
> to 1.5 required JDK level.

I agree.  I also wouldn't want to switch dbcp to a pool that
hasn't  
been heavily tested first.

> I'll attempt to put together one
>> in a few days.  Regardless, I don't think this is
something we should
>> target for this release.
>
> Before writing another one, have a look at the
compositepool package
> in pool head.

Well, I got this email after hacking on one for about 6
hours.  I the  
kind of person that needs to finish things I start, so I'm
going to  
keep hacking on it.  I will take a look at composite pool in
2.0 and  
assuming my version doesn't suck.  I'll see if I can merge
any of my  
good features into that code.  In the end I may just end up
wasting a  
lot of my time, but at least I'll learn how hard it is to
write a  
good pool

-dain


------------------------------------------------------------
---------
To unsubscribe, e-mail: commons-dev-unsubscribejakarta.apache.org
For additional commands, e-mail: commons-dev-helpjakarta.apache.org

On Jul 20, 2007, at 5:26 PM, Phil Steitz wrote:

> On 7/20/07, Dain Sundstrom <dainiq80.com> wrote:
>> On Jul 20, 2007, at 11:26 AM, Dain Sundstrom
wrote:
>>
>> > On Jul 19, 2007, at 11:19 PM, Phil Steitz
wrote:
>> >
>> >> I would love to have a fix for DBCP-44;
but that could wait on  
>> pool
>> >> 1.4 if necessary (and Ipersonally see no
way to fix it just within
>> >> dbcp.  It would be great if I was wrong on
that).
>> >
>> > I think the makeObject method is over
synchronized.  Actually, the
>> > class doesn't look it's synchronized properly
at all.  I'll take a
>> > shot at fixing this.
>>
>> I attached a patch that fixes the synchronization
in
>> PoolableConnectionFactory, but the deadlock still
persists.  The
>> problem is GenericObjectPool.borrowObject() is
synchronized so when
>> it needs to makeObject that method is called while
the synchronized
>> block is held.  I think this would take major
surgery to make
>> GenericObjectPool not perform this way.
>
> Thats what I feared.  Thanks for looking in any case.

Should I commit the patch that removes the excessive
synchronization  
from PoolableConnectionFactory.  It won't fix this problem
but may  
alleviate some other ones.

-dain

------------------------------------------------------------
---------
To unsubscribe, e-mail: commons-dev-unsubscribejakarta.apache.org
For additional commands, e-mail: commons-dev-helpjakarta.apache.org

On 7/23/07, Dain Sundstrom <dainiq80.com> wrote:
> On Jul 20, 2007, at 5:26 PM, Phil Steitz wrote:
>
> > On 7/20/07, Dain Sundstrom <dainiq80.com> wrote:
> >> On Jul 20, 2007, at 11:26 AM, Dain Sundstrom
wrote:
> >>
> >> > On Jul 19, 2007, at 11:19 PM, Phil Steitz
wrote:
> >> >
> >> >> I would love to have a fix for
DBCP-44; but that could wait on
> >> pool
> >> >> 1.4 if necessary (and Ipersonally see
no way to fix it just within
> >> >> dbcp.  It would be great if I was
wrong on that).
> >> >
> >> > I think the makeObject method is over
synchronized.  Actually, the
> >> > class doesn't look it's synchronized
properly at all.  I'll take a
> >> > shot at fixing this.
> >>
> >> I attached a patch that fixes the
synchronization in
> >> PoolableConnectionFactory, but the deadlock
still persists.  The
> >> problem is GenericObjectPool.borrowObject() is
synchronized so when
> >> it needs to makeObject that method is called
while the synchronized
> >> block is held.  I think this would take major
surgery to make
> >> GenericObjectPool not perform this way.
> >
> > Thats what I feared.  Thanks for looking in any
case.
>
> Should I commit the patch that removes the excessive
synchronization
> from PoolableConnectionFactory.  It won't fix this
problem but may
> alleviate some other ones.
>

+1 to committing the patch.

Phil

------------------------------------------------------------
---------
To unsubscribe, e-mail: commons-dev-unsubscribejakarta.apache.org
For additional commands, e-mail: commons-dev-helpjakarta.apache.org