tomcat-users mailing list archives

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

Sasidhar,

On 11/8/2010 12:31 AM, sasidhar prabhakar wrote:
> On Thu, Nov 4, 2010 at 9:10 PM, Christopher Schultz <
> chris@christopherschultz.net> 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
application.

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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkzZ180ACgkQ9CaO5/Lv0PDicACfZ/rv+FN8cT8JATK2ZlGYgWUW
CPoAn2/j0NO6af4RuL9t7j4yH9wXP+bW
=l181
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Mime
View raw message