(Per Phil Steitz's suggestion, I am moving our off list correspondence to this list.)
Thanks, Phil. I will see what I can find re the Oracle driver. Paul Gazda wrote: > Our DBAs did not have any useful log info, so I am going to try putting some > debugging statements in isClosed() to see if I can get any clues. > The isClosed() causing the problem is in the driver, not DBCP. What is causing the problem is that the *driver* is reporting the connection as closed when DBCP thinks the connection is open. You might try googling isClosed and the Oracle driver. As I said, I vaguely recall reports of the Oracle driver incorrectly reporting closed status of JDBC connections. > Paul Gazda > > -----Original Message----- > From: Phil Steitz [mailto:phil.ste...@gmail.com] > Sent: Wednesday, February 10, 2010 7:34 AM > To: Paul Gazda > Subject: Re: [VOTE] Release DBCP 1.3/1.4 based on RC7 > > Paul Gazda wrote: >> RE: Actually, if you just catch and ignore the SQLException on close, >> this will not deplete the pool as the pool as already invalidated >> the connection. So just enclosing your close statements in try - >> catch - ignore blocks should resolve your problem. >> >> Actually I had thought of that, but the problem is there are probably a >> hundred close statements across several applications. That is a lot of work, >> and I would need to code it to only ignore the "Already closed" error, the >> wording of which could change in the future. >> > > Unfortunately, I think the right solution for you is to find out > what is causing the connections to get closed - or at least for > Oracle to think they are closed - before they are returned to the > pool. This could be causing other problems that you don't yet know > about. > > I don't like the idea of having DBCP just swallow these exceptions. > > This discussion, btw, would be good to have on the commons-dev list. > > Phil >> Paul Gazda >> >> -----Original Message----- >> From: Phil Steitz [mailto:phil.ste...@gmail.com] >> Sent: Tuesday, February 09, 2010 7:02 PM >> To: Paul Gazda >> Subject: Re: [VOTE] Release DBCP 1.3/1.4 based on RC7 >> >> Paul Gazda wrote: >>> Phil, >>> Thanks for your comments. >>> >>> RE: Do you allow access to the underlying connection in your code and do >>> you manipulate - and possibly close - it anywhere? >>> Not as far as I know. I use this same pattern in many tomcat web >>> applications without issues: >>> DataSource ds = (DataSource)envCtx.lookup(DATASOURCE_CONTEXT_WEB); >>> Connection dbConn = ds.getConnection(); >>> ...do db stuff >>> dbConn.close(); >>> >>> The error occurs on dbConn.close(). >>> >>> RE: Is there some other process that can be closing physical connections >>> owned by the pool? Do you see anything in the database logs? >>> I have asked the DBAs to see if they can find anything. I'll work with them >>> on this. >>> >>> 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. >>> Could a solution be to simply throw the underlying connection away if it >>> has been closed? I know this could deplete the pool in a hurry if it >>> happened on every close, but in that case the pool would be depleted >>> whether errors were thrown or not. >>> >> Actually, if you just catch and ignore the SQLException on close, >> this will not deplete the pool as the pool as already invalidated >> the connection. So just enclosing your close statements in try - >> catch - ignore blocks should resolve your problem. >> >> Phil >> >> >>> Paul Gazda >>> >>> -----Original Message----- >>> From: Phil Steitz [mailto:phil.ste...@gmail.com] >>> Sent: Monday, February 08, 2010 6:33 PM >>> To: Paul Gazda >>> Subject: Re: [VOTE] Release DBCP 1.3/1.4 based on RC7 >>> >>> Paul Gazda wrote: >>>> Hello 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
