commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jason Lea <>
Subject Re: Production use of Connection Pooling
Date Tue, 15 Apr 2003 21:47:38 GMT
Frank Lawlor wrote:
> I thought I posted this a while ago, but can't find it in the archive,
> so I'll try again:
> I just went through a project where we looked at using the commons
> pooling in a production application.
> We found a number of serious problems with its use.  Anyone considering
> production use of the commons pooling or any pooling product should be
> aware of these issues.
> We also documented some programming practices for using pooled
> connections.
> To see these look in the White Papers section of
> for Jakarta_Pooling.doc and Proper_JDBC.doc

I have looked at the problem of 'REALLY Closing Connections'.

There is a reference to the 'bug' here

Rodney Waldhoff is right that you should not be calling 
PoolableConnection.reallyClose().  The pool does this for you when you 
return a connection.

If you have a bad connection and you think it shouldn't be reused you 
can call pool.invalidateObject(Object).  This also decrements the active 

 From the JavaDocs for invalidateObject():
"This method should be used when an object that has been borrowed is 
determined (due to an exception or other problem) to be invalid."

Of course the validateOnReturn might also help here to check your 
connections when you return them to the pool and if they are invalid 
they will be the reallyClosed.

Resource Leaks:
I have looked at this code and see that when you close a connection (a 
DelegateConnection), it will call passivate() which closes all 
Statements, PreparedStatements and ResultSets.

You should not be using the AbandonedObjectPool either because this 
introduces unpredictable behaviour to your application.  Relying on 
removeAbandoned() to clean up resources is asking for trouble.

You have already pointed out that the best way to deal with resource 
leaks is to close ResultSets, Statements etc in the application.  The 
only difficulty is making sure you remember to do this.

I think if commons-logging was added to DBCP would help a lot in finding 
places where people have forgotten to close them.  The 
DelegateConnection.passivate() could log any open Statements/ResultSets 
when it closes them.  Then the developer can hunt down where they should 
be closed nicely.

To help with debugging, I make sure I call global.getConnection() and 
global.closeConnection() methods in my application.  The getConnection 
does my commons-logging to record when connections are open, plus I 
store the hashcode and date it was opened into a (synchronized) HashMap. 
  It is removed when I call closeConnection, I also log the time the 
connection was open.  I can query this at anytime to find out how many 
connections are open and how long they have been open.  This has helped 
to find where connections are being left open.

Jason Lea

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

View raw message