RE: [dbcp]: DBCP 1.3 Already closed error

[Paul Gazda <Pa...@nau.edu>]

I finally got to the bottom of what was happening with the "already closed" error. Because of nested try-catch-finally blocks, I was missing the ultimate cause of the error in the stack trace (lesson learned to look more thoroughly at a stack trace even if it is very, very long). I put additional debug statements in my code and found that the connection was already closed at the time that the sql statement was executed, but the error message at the top of the stack trace was from the close statement in the finally block. This most often happened when the connections sat idle in the pool over night in my test environment. It does seem to be a hardware error of some sort. I solved the problem by adding testOnBorrow="true" to the resource definition.

We are left with the mystery of why the connections are becoming invalid in the pool, but it is infrequent enough that we will just live with it for now. So, I support Phil's statement of "My inclination is to leave as is, as either the driver is bugged or something bad is going on and I would want to know about it if it were my client code."

Thanks, Phil, for all of your help on this.

Paul Gazda


-----Original Message-----
From: Phil Steitz [mailto:phil.steitz@gmail.com] 
Sent: Wednesday, February 10, 2010 12:56 PM
To: Commons Developers List
Subject: [dbcp]: DBCP 1.3 Already closed error


A little more context on this.  From this trace below, you can see
that what is going on is the exception is thrown by
PoolableConnection.close(), which tests _conn.isClosed() (driver
call) before returning a connection to the pool.  If DBCP thinks the
connection is open - PoolableConnection.isClosed returns false - but
_conn.isClosed() returns true, then an SQLException is thrown, as
this indicates that the underlying JDBC connection was somehow
closed without DBCP knowing about it.

http://issues.apache.org/jira/browse/DBCP-193 gives s clue as to
what may be going on - Oracle 10g drivers will return true for
isClosed after a "End of File communication on CHannel" (ORA-03113)
occurs.

So the question is, do we reopen DBCP-193 and modify the code to
silently dispose of the connection when _conn.isClosed returns true,
or leave as is and force users to catch and handle this.  My
inclination is to leave as is, as either the driver is bugged or
something bad is going on and I would want to know about it if it
were my client code.

Phil
> 
>>>>> I'm a newcomer to the dbcp package. We have been trying to stop the "Already closed" errors that occur regularly but not predictably in our uPortal 2.6.1 application. I have compiled DBCP RC6 (the latest I could find in the public repository), and we still get the error:
> 
>>>>> Caused by: java.sql.SQLException: Already closed.
> 
>>>>>         at org.apache.commons.dbcp.PoolableConnection.close(PoolableConnection.java:114)
> 
>>>>>         at org.apache.commons.dbcp.PoolingDataSource$PoolGuardConnectionWrapper.close(PoolingDataSource.java:191)
> 
>>>>>         at edu.nau.its.sia.servlets.itssServlets.dao.OutageDao.getOutagesByDate(OutageDao.java:538)
> 
> 
>>>>> I have found a lot of bug issues related to this general problem, and tried applying the patches in DBCP-23 DBCP233 to 1.2.2, but that also failed to solve the problem. We are using Oracle 10.2.0.4 and tomcat 5.5.27, and the error occurs when a normal connection close statement is executed:  outageConn.close();
> 
> 
>>>>> Is this problem fixed in RC7, or could it be some other underlying problem not related to the DBCP code?
> 
> 
>>>>> Many thanks.
> 
> 
>>>>> Paul Gazda
> 
> 
> 
>>>> Hi Paul,
> 
> 
>>>> The error message may be a little misleading, but what is going on
> 
>>>> here is that the *underlying physical connection* has been closed
> 
>>>> when an attempt is made to return the connection handle to the pool.
> 
>>>> The bugs that you mention - which were fixed in DBCP 1.3/1.4 -
> 
>>>> addressed the problem that it was not previously possible to return
> 
>>>> a connection handle to the pool twice in sequence (i.e., to execute
> 
>>>> close twice on the same connection handle).
> 
> 
>>>> When a connection handle (PoolableConnection) is returned to the
> 
>>>> pool, the pool first checks to see if the underlying physical
> 
>>>> connection has been closed.  It uses Connection.isClosed() to check
> 
>>>> that.  (I vaguely recall some reports of some Oracle drivers not
> 
>>>> reporting this correctly in certain situations.)  If the underlying
> 
>>>> connection has been closed, an exception is thrown, as we don't want
> 
>>>> to return a handle to a closed physical connection to the pool.
> 
> 
>>>> Do you allow access to the underlying connection in your code and do
> 
>>>> you manipulate - and possibly close - it anywhere?
> 
> 
>>>> Is there some other process that can be closing physical connections
> 
>>>> owned by the pool?  Do you see anything in the database logs?
> 
> 
>>>> Since you grabbed the code, you can see what is going on by looking
> 
>>>> at the close method in PoolableConnection.  The _conn member is the
> 
>>>> underlying JDBC connection.
> 
> 
>>>> Phil
> 
> 
> 
> Paul Gazda
> 
> 


---------------------------------------------------------------------
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