commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Gazda <Paul.Ga...@nau.edu>
Subject DBCP 1.3 Already closed error
Date Wed, 10 Feb 2010 17:46:22 GMT
(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.steitz@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.steitz@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.steitz@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


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message