> Did you commit all transactions and set autoCommit to true before
> returning the connection to the pool? I don't know if the connection
> pool should do that for you... I will probably have to change the
> connection pool again, because the current behavior is probably not
> correct.
I always commit/rollback transactions, but adding autoCommit=true
before the connection close did the trick. All of the tests now pass
without any locking problems.
On the 88 tests I'm running, using FakeDataSource with DriverManager
getConnection took ~1.2 seconds, and using JdbcConnectionPool takes
~1.0 second. So it helps even for in-memory databases, and I can stop
using the FakeDataSource hack.
I have a utility Jdbc.closeSafely(conn) method that I could add
autoCommit=true to. Of course, adding it to the pool makes sense; but
it got me thinking--if you detected an autoCommit=false/open
transaction situation, would you auto-commit for the user or
auto-rollback?
Just adding a setAutoCommit(true) like I was initially adding to my
Jdbc.closeSafely would result in uncommitted transactions getting
committed. In my case, this typically would happen when an
exception had been thrown before the conn.commit(), with closeSafely
called from a finally block, so committing would be unexpected.
Huh...the java.sql.Connection.close javadoc says the behavior of close
with uncommitted transactions is implementation-defined.
So, here's what I went with:
if (!c.getAutoCommit()) {
c.rollback();
c.setAutoCommit(true);
}
c.close();
Thanks for the help,
Stephen
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "H2
Database" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/h2-database?hl=en
-~----------~----~----~----~------~----~------~--~---
