I'm not sure what is being proposed here, so if this is wrong let me
know. But code that is something like the following is not a good idea:
Connection con = pool.getConnection();
...do something...
con.close();
...
if (!con.isClosed())
con.close();
I think dbcp hands out the same Connection objects over and over again.
Once the first close() is called, another thread may access the
connection, so that now isClosed would return false and the connection
is closed again while another thread is using it.
The jdbc2 spec says that a pool should always return a new Connection
object from the getConnection method, and if dbcp does this, maybe this
coding style has some merit, though I am kind of confused as to its
purpose.
fyi, jdbc2pool in the sandbox does hand out new logical Connections for
each call to getConnection.
And once isClosed() returns true, it will always return true.
john mcnally
Anjan wrote:
>
> Hi Rodney!,
>
> Thank you for acknowledging that this could need a fix.
>
> Use Case : Our software can use multiple databases(oracle, mysql)
> at the same time. During initialization, I get a connection from each
> database and do some queries in a LOOP. The finally {} block cleans up any
> connections if there were any exceptions. That's where I try to find if
> it's closed -- connection.isClose() . If it's not closed, I close it to
> prevent leakage.
>
> FIX : You understood me correctly. Yes, As far as the client program is
> concerned, if a previous block of code has already closed the connection,
> then the connection.isClosed() should return true. To get this
> behavior, we need to modify PoolableConnection? Can you suggest how to fix
> this ?
>
> Thank you,
>
> Best Regards,
> ANJAN. B
>
> -----Original Message-----
> From: Waldhoff, Rodney [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, April 02, 2002 1:32 PM
> To: 'Jakarta Commons Developers List'
> Subject: RE: [DBCP] : DelegatingConnection/PoolableConnection Bug ?
>
> Can't say that I use Connection.isClosed often if at all, nor that I fully
> understand the use cases here.
>
> Technically speaking, if the underlying connection isn't closed, then
> PoolableConnection still has an open channel to the database. Does that
> mean isClosed should return true?
>
> I think you're suggesting that PoolableConnection.isClosed should return
> true when the connection is in the pool, false when it's out of the pool
> (and the underlying connection isn't closed either). Sounds reasonable to
> me.
>
> --
> To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
