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)
- robert
8 messages in org.apache.commons.devRe: Dbcp unit test failures with Pool...