tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Schultz <>
Subject Re: DBCP abandoned trace - unable to understand the leak
Date Tue, 09 Nov 2010 23:22:54 GMT
Hash: SHA1


On 11/8/2010 12:31 AM, sasidhar prabhakar wrote:
> On Thu, Nov 4, 2010 at 9:10 PM, Christopher Schultz <
>> wrote:
>> I have found that these exceptions can occur even when there is no leak.
>> Specifically, if your SQL query takes a long time to run (that is, more
>> than the ababdonedTimeout), another request to the connection pool
>> complains about the connection and calls it abandoned.
> I think your right. Timeout  I mentioned 30sec deafault is 300sec. This is
> my context.xml

> <?xml version="1.0" encoding="UTF-8"?>
> <Context path="" >

"path" is not allowed in context.xml: remove it.

> validationQuery="SELECT * from dual"

SELECT *? Wow. How about "SELECT 1 FROM dual"?

> testOnBorrow="true"
> removeAbandoned="true"
> removeAbandonedTimeout="30"

That's a 30-second abandoned timeout.

> username="scott"
> password="*******"

"tiger", right?

>> Technically speaking, the connection hasn't been leaked, but the
>> connection pool can't really guess the reason why the connection hasn't
>> been returned.
>> Can you time your queries to see how long they take? Could you post your
>> <Resource> configuration for your DataSource?
> For some queries it took more than 30 seconds, from getting data from
> ip_to_geo table, which has 3 million rows in it.

That could be your problem: you should probably increase your
removeAbandonedTimeout value to something more appropriate for your

You might also want a dba to check out your queries and your database
structure. 3 million rows isn't that much, even for Oracle :)

>> Another note: I notice that you are using a DataSource object that
>> survives for the life of the DAO object, and is even created by the
>> object in its constructor.
> Every DAO has only one instance for the entire life of application. Is this
> correct approach. So Every thread accessing the same datasource object to
> get connection.

It was just a recommendation which gives you flexibility: your webapp
(or the container, etc.) has the freedom to discard and completely
re-build the DataSource for your webapp if you always go to the JNDI
context to get the DataSource. Otherwise, you will force a webapp
restart just to get a new DataSource.

- -chris
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla -


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message