commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bill Davidson <>
Subject Re: DBCP woes (running out of cursors).
Date Thu, 15 Oct 2009 21:07:07 GMT
Christopher Schultz wrote:
 >Probably not. DBCP calls setAutoCommit(true) by default in order to
 >reset the connection as it goes back into the pool. Any pending
 >transaction is committed (!) when that happens, so there shouldn't be
 >any in-progress transactions lingering around.
 >If you set autoCommit="false" in your DBCP configuration, that might
 >change things. Are your transaction finally blocks and commit/rollback
 >logic blocks sane? You can refer to my previously-mentioned blog post
 >for my thoughts on how to do it properly.

I'm a little confused about auto-commit.  I don't want my transactions
auto-committed.  Sometimes there's a need for a rollback of an entire
transaction.  To my thinking, auto-commit implies that you don't have
true transactions.

The transactions in the app are a lot more complex, and a transaction
can hold onto a connection for quite a while as a user is editing things.
The queries themselves have the same try-catch-finally situation but
there can be quite a few different calls on that connection for one

 >But what is the likelihood of "SELECT * FROM foo WHERE"
 >appearing in a transaction?

Very low.  The scenario I was describing was:

1. Thread 1 returns a connection with an uncommitted transaction to the 
2. Thread 2 gets the same connection from the pool and does a query on it
3. The query from Thread 2, unrelated Thread 1, ends up in cursor limbo
   because of the uncommitted transaction on the connection.

I don't know that this is happening in the app, and it's going to be very
difficult to find it if it is.  I don't even know that this scenario 
could cause this
cursor limbo.  It's just a hypothesis which is hard to test.

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

View raw message