commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Phil Steitz" <phil.ste...@gmail.com>
Subject Re: Dbcp unit test failures with Pool 1.3 [was: [VOTE] Release Pool 1.3 based on 1.3-rc4]
Date Wed, 29 Mar 2006 02:32:53 GMT
On 3/28/06, robert burrell donkin <robertburrelldonkin@blueyonder.co.uk> wrote:
> On Mon, 2006-03-27 at 19:43 -0700, Phil Steitz wrote:
> > <snip/>
> > > * testPooling: This test method passes when you run it by itself. It
> > > fails because while it looks like it's written to handle either a FIFO
> > > or a LIFO pool implementation it doesn't if the GenericObjectPool
> > > backing Dbcp has more than 2 idle connections. When the test is run
> > > after other tests the GOP contains 4 idle connections. With a LIFO the
> > > most recently returned is the first one borrowed so it doesn't matter
> > > how many idle connections already exist at the start of the test.
> > > Since GOP is now a FIFO the test fails because is incorrectly assumes
> > > that a recently returned connection will be the next one borrowed. IMO
> > > testPooling should be removed as it really testing Pool's behavior and
> > > not Dbcp's behavior.
> >
> > Yes.  This is bad and I agree this test case should be removed, as it
> > depends on the implementation of the underlying pool, which is not
> > part of [dbcp].  If there are no objections, I will remove this test
> > case.
>
> or replace with a mock pool implementation (if possible)

This is an interesting idea.  Would appreciate suggestions on how
exactly to do this.

Phil

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message