commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dirk Verbeeck <dirk.verbe...@pandora.be>
Subject Re: [dbcp] Support for debugging leaking connections?
Date Mon, 14 Feb 2005 17:24:57 GMT
Hi

You are looking for the removeAbandoned feature.
http://jakarta.apache.org/commons/dbcp/configuration.html

logAbandoned will log stacktraces of the getConnection() call made to 
retrieve the lost connection. Depending on your application design 
this might be enough to find the leak.
There isn't a best approach, it all depends on your connection handling.

Connections who are allocated/freed inside a single method are easy, 
the only catch there is exception handling (close in finally block).

If you have a session or request like object you can store the 
connection in there and give it as a parameter to all the database 
methods (carefully counting these object creation/destruction, to 
debug this case).

Oracle can give you the last query executed on each connection using a 
dba tool (other database probably have this as well), this can help 
you find the error.

The last resort is to add log4j statements to each getConnection/close 
pair and analyse the logfile offline for missing close. (use NDC from 
log4j to mark each thread with a unique identifier)
You could use aspectJ for this logging but again all depends on the 
code structure of the project.

Cheers
Dirk

Fredrik Jonson wrote:
> Hello, 
> 
> I have recently been handed a project, which uses connection
> poolign and appears to leak connections. Unfortunately a source
> code review haven't hinted of any obvious errors.
> 
> Is there any way to make dbcp forcefully revoke connections after
> some timeout? Is this built in, and if not, what is a good
> approach to implementing it?
> 
> Basically, my idea is that revoking connections will sooner or
> later make the application throw a nullpointer exception during
> tests. 
> 
> Generally, am I approaching the problem in a sensible way, or is
> there a better approach?
> 
> TIA, regards,



---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org


Mime
View raw message