commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kenneth Corbin <ke...@peak.org>
Subject [dbcp] Lessons learned from another connection pool
Date Sun, 22 Feb 2004 07:33:18 GMT
I wrote my own connection pool, that I thought was pretty cool, but that was 
before I started looking at jakarta commons products.  Now it looks pretty 
pathetic compared to dbcp, but I did learn a couple things from it that might 
you might not have covered.

The big gotcha was the need to rollback any uncommited transactions before 
returning a connection to the pool.  I didn't do that originally, and sure 
that my best theory as to why we were experiencing unpredictable database 
deadlocks.  Someone released a connection with an uncommitted transaction, I 
stuck it back in the pool with locks still pending, and everyone else piled 
up behind them.  I didn't see anything in the PoolableConnection class that 
looked like you were calling rollback before returning a connection to the 
pool, but it could easily be somewhere else.

An earlier discovery is that when we loose a network connection to an Oracle 
database.  The first symptom is that an attempt to reset the autocommit 
status threw an exception.   That might be something you want to try in the 
validate method if a validation string hasn't been specified.

Featurewise, mine will pool prepared statements accross a close.   As best I 
can tell, dbcp really closes pooled statements when the the user closes the 
connection and they have to be rebuilt the next time a connection is 
allocated from the pool.  I would probably be a nice idea to at least have 
the option to keep the statement pool from one connection allocation to the 
next.


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


Mime
View raw message