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: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
