commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bill Davidson <bill...@gmail.com>
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
transaction.

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

Very low.  The scenario I was describing was:

1. Thread 1 returns a connection with an uncommitted transaction to the 
pool.
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: user-unsubscribe@commons.apache.org
For additional commands, e-mail: user-help@commons.apache.org


Mime
View raw message